* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management [not found] ` <3bOUc.46253$US4.14922@trndny01> @ 2004-08-19 0:37 ` Richard Riehle 2004-08-19 4:54 ` Thomas G. Marshall 0 siblings, 1 reply; 9+ messages in thread From: Richard Riehle @ 2004-08-19 0:37 UTC (permalink / raw) "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in message news:3bOUc.46253$US4.14922@trndny01... > Richard Riehle <adaworks@earthlink.net> coughed up the following: > > Please give us an example of a type definition that > > is difficult to catch and fix. > > > > Richard Riehle > > I don't understand what you're asking him. Are you saying that you've never > seen a complicated model with a set of types that was ever so slightly /off/ > the mark so that it was difficult to discover, and also laborious to fix? > There are several parts to your question. 1) Complicated model 2) Incorrect types ("ever so slightly /off/ the mark 3) Difficult to discover 4) Laborious to fix My experienc iis primarily with Ada, so these questions are not quite as relevant as they might be in some other language. Nevertheless, I will answer them. I have seen designs where the there were too many types defined. In particular, people sometimes design too many floating point types. For example, package Real_Numbers is type Real is digits 8 range -2000.0 .. 2000.0; type Degree is digits 6 range 0.0 .. 360.0; -- and many more such definitions end Real_Numbers; In the above example, it might be more useful to derived Degree from Real, or create an Ada subtype (I will not define the difference here, but it is different) from Real for Degree. When there are too many variations on floating point, one often has to do too much type conversion elsewhere within the program. However, Ada never lets you get this wrong. As to incorrect types, this will most often occur in composite types, especially record types. On might forget to include a component of the type in the definition. Since record types, in Ada, are most frequently defined as "limited" types, they are not part of the public part of a specification. This makes it quite easy to correct them without disturbing the integrity of the underlying specification. As to being difficult to discover, I have not seen this very often in programming with Ada. The language is designed so the compiler will quickly highlight any inconsistencies. The compilation process is not based on textual information alone. Each unit that depends on another unit requires the unit on which it depends is successfully compiled first. The compiler will not even begin to compile a unit unless its dependency relationships have been resolved. This lends itself to rapid discovery of problems with type definitions. When we consider laborious to fix, I rarely find that to be a problem. In fact, I cannot think of the last time (in nearly 20 years) where the problem with a type was laborious to fix. Certainly, when I was a novice there were problems I could not easily resolve. With experience, I have found that well-designed Ada does not entertain me with the kind of mysterious errors I sometimes encounter in other languages. I realize that most readers do not benefit fromt the Ada static compilation model. Still, that model does have the appeal, to those who do enjoy it, of making the type system a blessing rather than a nuisance. Now. I would still like to see some examples of type problems that correspond to the four points in your reply, above. Richard Riehle ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management 2004-08-19 0:37 ` Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management Richard Riehle @ 2004-08-19 4:54 ` Thomas G. Marshall 2004-08-19 8:10 ` Dmitry A. Kazakov ` (3 more replies) 0 siblings, 4 replies; 9+ messages in thread From: Thomas G. Marshall @ 2004-08-19 4:54 UTC (permalink / raw) Richard Riehle <adaworks@earthlink.net> coughed up the following: > "Thomas G. Marshall" > <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in > message news:3bOUc.46253$US4.14922@trndny01... >> Richard Riehle <adaworks@earthlink.net> coughed up the following: >>> Please give us an example of a type definition that >>> is difficult to catch and fix. >>> >>> Richard Riehle >> >> I don't understand what you're asking him. Are you saying that >> you've never seen a complicated model with a set of types that was >> ever so slightly /off/ the mark so that it was difficult to >> discover, and also laborious to fix? >> > There are several parts to your question. > > 1) Complicated model > 2) Incorrect types ("ever so slightly /off/ the mark > 3) Difficult to discover > 4) Laborious to fix > > My experienc iis primarily with Ada, so these questions are not quite > as relevant as they might be in some other language. Nevertheless, > I will answer them. > > I have seen designs where the there were too many types defined. In > particular, people sometimes design too many floating point types. > For example, > > package Real_Numbers is > type Real is digits 8 range -2000.0 .. 2000.0; > type Degree is digits 6 range 0.0 .. 360.0; > -- and many more such definitions > end Real_Numbers; > > In the above example, it might be more useful to derived Degree from > Real, or create an Ada subtype (I will not define the difference > here, but it is different) from Real for Degree. When there are too > many variations on floating point, one often has to do too much type > conversion elsewhere within the program. However, Ada never lets > you get this wrong. > > As to incorrect types, this will most often occur in composite types, > especially > record types. On might forget to include a component of the type in > the definition. Since record types, in Ada, are most frequently > defined as "limited" types, they are not part of the public part of > a specification. This makes it quite easy to correct them without > disturbing the integrity of the underlying specification. > > As to being difficult to discover, I have not seen this very often in > programming > with Ada. The language is designed so the compiler will quickly > highlight any > inconsistencies. The compilation process is not based on textual > information > alone. Each unit that depends on another unit requires the unit on > which it > depends is successfully compiled first. The compiler will not even > begin to compile a unit unless its dependency relationships have been > resolved. > This > lends itself to rapid discovery of problems with type definitions. > > When we consider laborious to fix, I rarely find that to be a > problem. In fact, > I cannot think of the last time (in nearly 20 years) where the > problem with a type was laborious to fix. Certainly, when I was a > novice there were problems I could not easily resolve. With > experience, I have found that well-designed Ada does not entertain me > with the kind of mysterious > errors I sometimes encounter in other languages. > > I realize that most readers do not benefit fromt the Ada static > compilation model. Still, that model does have the appeal, to those > who do enjoy > it, of making the type system a blessing rather than a nuisance. > > Now. I would still like to see some examples of type problems that > correspond > to the four points in your reply, above. > > Richard Riehle Without having to hand you an inch thick spec......ok. Here: Think java applet running on a pc. That pc connected to a very complicated scientific device, composed of a great many number producing things. I'm going to use the term "gui component" here, but I really mean more than View, but also the Model/Controller folded in as well. One of my java clients needed a very complicated multi-layered gui, where each of the visual components (meters, text fields, flashing lights, text labels grayed out, red, or red/gray, or blinking), had to in real time reflect what was happening to that component's counterpart within another device. A ton of meterable "things" in the device, and a ton of real time gui elements in the java app reflecting the various values, states, warning levels, what have you. Many of the gui items further controlled other "things" in the device, which caused only a cascade of changes in the gui elements that were monitoring the components from the device. For a huge part of the development, the gui components were designed around their own threads. One drawn LED that needed to be updated 5 times a second, one thread. A textfield next to it that needed to be updated 25 times a second, another thread. Each of those threads ran in real time collecting (and sometimes sending) to/from the device. When the number of such continually active gui components threatened to exceed several hundred, we shifted the model and from the top converted every single component into an entry into something called the Dispatch. Dispatch maintained a list(1) of lists(2) of components. Each list(2) was a list of components that needed updating a particular interval. All the 50ms updates went into one such list. All slower 150ms updates went into another, etc. 23 distinct interval types meant 23 entries in list(1), each of which a list(2) of components. Because it was done in Java, a statically typed language, there was a great deal of energy spent in just turning the crank of making sure that the types shifted from prior strategy to the current one. I hope I've been clear enough here. -- Framsticks. 3D Artificial Life evolution. You can see the creatures that evolve and how they interact, hunt, swim, etc. http://www.frams.alife.pl/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management 2004-08-19 4:54 ` Thomas G. Marshall @ 2004-08-19 8:10 ` Dmitry A. Kazakov 2004-08-19 16:24 ` Thomas G. Marshall 2004-08-19 12:52 ` Jim Rogers ` (2 subsequent siblings) 3 siblings, 1 reply; 9+ messages in thread From: Dmitry A. Kazakov @ 2004-08-19 8:10 UTC (permalink / raw) On Thu, 19 Aug 2004 04:54:42 GMT, Thomas G. Marshall wrote: > Without having to hand you an inch thick spec......ok. Here: > > Think java applet running on a pc. That pc connected to a very complicated > scientific device, composed of a great many number producing things. I'm > going to use the term "gui component" here, but I really mean more than > View, but also the Model/Controller folded in as well. > > One of my java clients needed a very complicated multi-layered gui, where > each of the visual components (meters, text fields, flashing lights, text > labels grayed out, red, or red/gray, or blinking), had to in real time > reflect what was happening to that component's counterpart within another > device. > > A ton of meterable "things" in the device, and a ton of real time gui > elements in the java app reflecting the various values, states, warning > levels, what have you. Many of the gui items further controlled other > "things" in the device, which caused only a cascade of changes in the gui > elements that were monitoring the components from the device. > > For a huge part of the development, the gui components were designed around > their own threads. One drawn LED that needed to be updated 5 times a > second, one thread. A textfield next to it that needed to be updated 25 > times a second, another thread. Each of those threads ran in real time > collecting (and sometimes sending) to/from the device. > > When the number of such continually active gui components threatened to > exceed several hundred, we shifted the model and from the top converted > every single component into an entry into something called the Dispatch. > Dispatch maintained a list(1) of lists(2) of components. Each list(2) was a > list of components that needed updating a particular interval. All the 50ms > updates went into one such list. All slower 150ms updates went into > another, etc. 23 distinct interval types meant 23 entries in list(1), each > of which a list(2) of components. > > Because it was done in Java, a statically typed language, there was a great > deal of energy spent in just turning the crank of making sure that the types > shifted from prior strategy to the current one. I hope I've been clear > enough here. 1. I would say that it was a design fault. The idea to use active objects for GUI instruments is wrong. We used to design several similar projects and never tried to go that way, because it is so obviously(?) wrong. GUI instruments should be passive controlled by "referesh" threads from outside. Also that they should not directly communicate with neither actors nor sensors (devices), but do it through a middleware interface. 2. I don't see why re-design (an expensive thing) should be easier with dynamic types. [ You have to change, say, 30% of the code. If that 30% is largely about types, then dealing with Ada I would prefer that. Because the compiler can help me there. If that changes are about implementations, then it is usually more painful. Please, do not tell me that in Smalltalk that will be 0%! You have a design fault. So it will be still same 30% distributed all over the code. ] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management 2004-08-19 8:10 ` Dmitry A. Kazakov @ 2004-08-19 16:24 ` Thomas G. Marshall 0 siblings, 0 replies; 9+ messages in thread From: Thomas G. Marshall @ 2004-08-19 16:24 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> coughed up the following: > On Thu, 19 Aug 2004 04:54:42 GMT, Thomas G. Marshall wrote: > >> Without having to hand you an inch thick spec......ok. Here: >> >> Think java applet running on a pc. That pc connected to a very >> complicated scientific device, composed of a great many number >> producing things. I'm going to use the term "gui component" here, >> but I really mean more than View, but also the Model/Controller >> folded in as well. >> >> One of my java clients needed a very complicated multi-layered gui, >> where each of the visual components (meters, text fields, flashing >> lights, text labels grayed out, red, or red/gray, or blinking), had >> to in real time reflect what was happening to that component's >> counterpart within another device. >> >> A ton of meterable "things" in the device, and a ton of real time gui >> elements in the java app reflecting the various values, states, >> warning levels, what have you. Many of the gui items further >> controlled other "things" in the device, which caused only a cascade >> of changes in the gui elements that were monitoring the components >> from the device. >> >> For a huge part of the development, the gui components were designed >> around their own threads. One drawn LED that needed to be updated 5 >> times a second, one thread. A textfield next to it that needed to >> be updated 25 times a second, another thread. Each of those threads >> ran in real time collecting (and sometimes sending) to/from the >> device. >> >> When the number of such continually active gui components threatened >> to exceed several hundred, we shifted the model and from the top >> converted every single component into an entry into something called >> the Dispatch. Dispatch maintained a list(1) of lists(2) of >> components. Each list(2) was a list of components that needed >> updating a particular interval. All the 50ms updates went into one >> such list. All slower 150ms updates went into another, etc. 23 >> distinct interval types meant 23 entries in list(1), each of which a >> list(2) of components. >> >> Because it was done in Java, a statically typed language, there was >> a great deal of energy spent in just turning the crank of making >> sure that the types shifted from prior strategy to the current one. >> I hope I've been clear enough here. > > 1. I would say that it was a design fault. The idea to use active > objects > for GUI instruments is wrong. We used to design several similar > projects > and never tried to go that way, because it is so obviously(?) wrong. Stay off your high horse. > GUI instruments should be passive controlled by "referesh" threads > from > outside. They were. Actually, that's not "passive", that's /actively/ controlled and controlling, because many of the gui elements were dual duty: they move as accessors, but can be moved (by user) to mutate. > Also that they should not directly communicate with neither > actors nor sensors (devices), but do it through a middleware > interface. We did that too. From the beginning. When I'm refering to gui components, I'm refering to /all/ that it takes for the gui component to work. Remember, this has to be a quick sketch of what was going on. ...[rip]... -- http://www.allexperts.com is a nifty way to get an answer to just about /anything/. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management 2004-08-19 4:54 ` Thomas G. Marshall 2004-08-19 8:10 ` Dmitry A. Kazakov @ 2004-08-19 12:52 ` Jim Rogers 2004-08-19 16:31 ` Thomas G. Marshall 2004-08-20 1:27 ` Stephen Leake 2004-08-20 7:00 ` Richard Riehle 3 siblings, 1 reply; 9+ messages in thread From: Jim Rogers @ 2004-08-19 12:52 UTC (permalink / raw) "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in news:moWUc.5028$de4.548@trndny07: > > Without having to hand you an inch thick spec......ok. Here: > > Think java applet running on a pc. That pc connected to a very > complicated scientific device, composed of a great many number > producing things. I'm going to use the term "gui component" here, but > I really mean more than View, but also the Model/Controller folded in > as well. > > One of my java clients needed a very complicated multi-layered gui, > where each of the visual components (meters, text fields, flashing > lights, text labels grayed out, red, or red/gray, or blinking), had to > in real time reflect what was happening to that component's > counterpart within another device. > > A ton of meterable "things" in the device, and a ton of real time gui > elements in the java app reflecting the various values, states, > warning levels, what have you. Many of the gui items further > controlled other "things" in the device, which caused only a cascade > of changes in the gui elements that were monitoring the components > from the device. > > For a huge part of the development, the gui components were designed > around their own threads. One drawn LED that needed to be updated 5 > times a second, one thread. A textfield next to it that needed to be > updated 25 times a second, another thread. Each of those threads ran > in real time collecting (and sometimes sending) to/from the device. > > When the number of such continually active gui components threatened > to exceed several hundred, we shifted the model and from the top > converted every single component into an entry into something called > the Dispatch. Dispatch maintained a list(1) of lists(2) of components. > Each list(2) was a list of components that needed updating a > particular interval. All the 50ms updates went into one such list. > All slower 150ms updates went into another, etc. 23 distinct interval > types meant 23 entries in list(1), each of which a list(2) of > components. > > Because it was done in Java, a statically typed language, there was a > great deal of energy spent in just turning the crank of making sure > that the types shifted from prior strategy to the current one. I hope > I've been clear enough here. I think you may be painting with too broad of a brush. I see several problems in your description. One problem was the choice of your initial design. Applets typically run on a single processor. Unless you apply very careful design, a multi-threaded application on a single processor will usually run slower than a single-threaded application doing the same conceptual work. Threading introduces overheads such as scheduling and locking, which are not encountered in a single-threaded application. Another problem is the choice of Java itself. Java threading is non-deterministic. The Java coding model mixes the concept of a type and a thread to the point that they are very hard to separate if threads are rejected late in the development process. Your task of stripping out the threading would have been much easier if types and threads were orthoginal to each other. You still had some performance challenges in the new design, with nested timing loops. It is possible that one of your list(2) lists would get large enough that the processor/language combination could not activate all events in a list(2) within the specified performance boundary. You would get timing creep that could affect all the events in your list of lists system. It is very important to balance nested control loops. Once balanced, those control loops provide a difficult challenge during maintenance. Any additions or deletions from any list(2) could potentially upset the timing of all loops. Changes must be made in delays for each nested loop level to compensate for the changes in the size of lists. Notice that these problems are independent of whether a language type system is dynamic or static. Jim Rogers ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management 2004-08-19 12:52 ` Jim Rogers @ 2004-08-19 16:31 ` Thomas G. Marshall 0 siblings, 0 replies; 9+ messages in thread From: Thomas G. Marshall @ 2004-08-19 16:31 UTC (permalink / raw) Jim Rogers <jimmaureenrogers@worldnet.att.net> coughed up the following: > "Thomas G. Marshall" > <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in > news:moWUc.5028$de4.548@trndny07: > >> >> Without having to hand you an inch thick spec......ok. Here: >> >> Think java applet running on a pc. That pc connected to a very >> complicated scientific device, composed of a great many number >> producing things. I'm going to use the term "gui component" here, >> but I really mean more than View, but also the Model/Controller >> folded in as well. >> >> One of my java clients needed a very complicated multi-layered gui, >> where each of the visual components (meters, text fields, flashing >> lights, text labels grayed out, red, or red/gray, or blinking), had >> to in real time reflect what was happening to that component's >> counterpart within another device. >> >> A ton of meterable "things" in the device, and a ton of real time gui >> elements in the java app reflecting the various values, states, >> warning levels, what have you. Many of the gui items further >> controlled other "things" in the device, which caused only a cascade >> of changes in the gui elements that were monitoring the components >> from the device. >> >> For a huge part of the development, the gui components were designed >> around their own threads. One drawn LED that needed to be updated 5 >> times a second, one thread. A textfield next to it that needed to be >> updated 25 times a second, another thread. Each of those threads ran >> in real time collecting (and sometimes sending) to/from the device. >> >> When the number of such continually active gui components threatened >> to exceed several hundred, we shifted the model and from the top >> converted every single component into an entry into something called >> the Dispatch. Dispatch maintained a list(1) of lists(2) of >> components. Each list(2) was a list of components that needed >> updating a particular interval. All the 50ms updates went into one >> such list. All slower 150ms updates went into another, etc. 23 >> distinct interval types meant 23 entries in list(1), each of which a >> list(2) of components. >> >> Because it was done in Java, a statically typed language, there was a >> great deal of energy spent in just turning the crank of making sure >> that the types shifted from prior strategy to the current one. I >> hope I've been clear enough here. > > I think you may be painting with too broad of a brush. I see several > problems in your description. One problem was the choice of your > initial design. Applets typically run on a single processor. Unless > you apply very careful design, a multi-threaded application on a > single processor will usually run slower than a single-threaded > application doing the same conceptual work. Threading introduces > overheads such as scheduling and locking, which are not encountered > in a single-threaded application. > > Another problem is the choice of Java itself. Java threading is > non-deterministic. The Java coding model mixes the concept of a type > and a thread to the point that they are very hard to separate if > threads are rejected late in the development process. Your task of > stripping out the threading would have been much easier if types and > threads were orthoginal to each other. > > You still had some performance challenges in the new design, with > nested timing loops. It is possible that one of your list(2) lists > would get large enough that the processor/language combination could > not activate all events in a list(2) within the specified performance > boundary. You would get timing creep that could affect all the events > in your list of lists system. It is very important to balance nested > control loops. Once balanced, those control loops provide a difficult > challenge during maintenance. Any additions or deletions from any > list(2) could potentially upset the timing of all loops. Changes must > be made in delays for each nested loop level to compensate for the > changes in the size of lists. > > Notice that these problems are independent of whether a language type > system is dynamic or static. {sigh}. Design 101 was not lost on us. Neither is Common Sense 801. I don't have the energy to discuss the design in its entirety, nor walk through all the decisions, the reasoning, the background, the customer demands, etc., etc.----it'd be unreasonable to assume that such a conversation would even be /possible/ over usenet. I was asked for an example of: <quotezilla> 1) Complicated model 2) Incorrect types ("ever so slightly off the mark 3) Difficult to discover 4) Laborious to fix </quotezilla> The reasons /why/ these decisions were made? The discussion of it per se, is of zero importance. Please, save your time and mine---you'll /never/ get the full picture---this was a large project with many layers of design. -- http://www.allexperts.com is a nifty way to get an answer to just about /anything/. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management 2004-08-19 4:54 ` Thomas G. Marshall 2004-08-19 8:10 ` Dmitry A. Kazakov 2004-08-19 12:52 ` Jim Rogers @ 2004-08-20 1:27 ` Stephen Leake 2004-08-20 7:00 ` Richard Riehle 3 siblings, 0 replies; 9+ messages in thread From: Stephen Leake @ 2004-08-20 1:27 UTC (permalink / raw) To: comp.lang.ada "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> writes: > <snip description of complex GUI / instrument system> > > Because it was done in Java, a statically typed language, there was a great > deal of energy spent in just turning the crank of making sure that the types > shifted from prior strategy to the current one. I hope I've been clear > enough here. I gather you believe it would have been easier to do this redesign in some other language? What language, and why? If I had done the same thing in Ada (and I have done similar redesigns (I call it "refactoring")), I would expect to "turn the crank" to get all the types right. That's part of what static typing is for; the compiler lets you know where stuff has to be changed. But at each point, you need to make sure that nothing _else_ needs to be changed; often it does. So I don't see why you feel "turning the crank" is a Bad Thing here. -- -- Stephe ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management 2004-08-19 4:54 ` Thomas G. Marshall ` (2 preceding siblings ...) 2004-08-20 1:27 ` Stephen Leake @ 2004-08-20 7:00 ` Richard Riehle 3 siblings, 0 replies; 9+ messages in thread From: Richard Riehle @ 2004-08-20 7:00 UTC (permalink / raw) "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in message news:moWUc.5028$de4.548@trndny07... > Richard Riehle <adaworks@earthlink.net> coughed up the following: > > "Thomas G. Marshall" > > When the number of such continually active gui components threatened to > exceed several hundred, we shifted the model and from the top converted > every single component into an entry into something called the Dispatch. > Dispatch maintained a list(1) of lists(2) of components. Each list(2) was a > list of components that needed updating a particular interval. All the 50ms > updates went into one such list. All slower 150ms updates went into > another, etc. 23 distinct interval types meant 23 entries in list(1), each > of which a list(2) of components. > > Because it was done in Java, a statically typed language, there was a great > deal of energy spent in just turning the crank of making sure that the types > shifted from prior strategy to the current one. I hope I've been clear > enough here. > Yes, you are clear. I see that, with Java, and the approach to design you describe, you could get annoyed with the static typing, the length of time to change things, and the difficulty of finding the exact problem in each case. I also see that, with Ada, designing the types in well formed packages and separating the visible part of a type from its structure (i.e., the name of the type from how it is defined), this problem is largely non-existent. Thanks. Richard Riehle ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <TgfUc.122489$M95.15934@pd7tw1no>]
[parent not found: <XtOUc.4483$QJ3.4254@newssvr21.news.prodigy.com>]
* Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management [not found] ` <XtOUc.4483$QJ3.4254@newssvr21.news.prodigy.com> @ 2004-08-19 0:39 ` Richard Riehle 0 siblings, 0 replies; 9+ messages in thread From: Richard Riehle @ 2004-08-19 0:39 UTC (permalink / raw) "Kelly Hall" <khall@acm.org> wrote in message news:XtOUc.4483$QJ3.4254@newssvr21.news.prodigy.com... > Jeff Brooks wrote: > > > The problem is static type checking is a very weak form of testing. > > That's because most programming languages have very weak type systems. > I strongly advocate beefier type systems. > > As long as you're willing to write every test case you care about - no > wonder you want to spend less time in the editor :) As a formal methods > guy, I'd much rather write one proof and ignore a whole class of test > cases. Ideally, my compiler would do most of the proofs for me. But > we're not there yet - more's the pity. > May I suggest you take a serious look at the Praxis Software SPARK development model. As "a formal methods guy," you will probably appreciate the contribution of SPARK. Richard Riehle ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-08-20 7:00 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1hk5j2d3dlmrp$.153lae83darml$.dlg@40tude.net> [not found] ` <40f29222@alpha.wvnet.edu> [not found] ` <104x9d9d53127$.1b8jq22ldf2js.dlg@40tude.net> [not found] ` <40f2ee18@alpha.wvnet.edu> [not found] ` <8yhg4xv40agi.ly9pgul3h7jw$.dlg@40tude.net> [not found] ` <40f3ceee@alpha.wvnet.edu> [not found] ` <19iip59qsl122$.3g3hicltra17.dlg@40tude.net> [not found] ` <40f5bbe1@alpha.wvnet.edu> [not found] ` <lLCdnT5s5oBR0mvdRVn-vw@nildram.net> [not found] ` <40f67c13@alpha.wvnet.edu> [not found] ` <b46dnTyZeOwARmrdRVn-sA@nildram.net> [not found] ` <nisfh0hq8n83kckuss0g2m8dclchbb87c4@4ax.com> [not found] ` <9qTRc.61502$M95.25853@pd7tw1no> [not found] ` <ce7ef1c8.0408100846.7cd312e8@posting.google.com> [not found] ` <BuASc.81568$gE.9811@pd7tw3no> [not found] ` <411C5D2F.5070408@acm.org> [not found] ` <BZxTc.103385$M95.61358@pd7tw1no> [not found] ` <ifGTc.574$SR4.140@newssvr14.news.prodigy.com> [not found] ` <bkiuh054vd4suvd2fgqmekvt9llaend5n1@4ax.com> [not found] ` <tNydnW_KyNuXHL3cRVn-oQ@nildram.net> [not found] ` <nu2dnc4HfY-2Wb_cRVn-sQ@fcc.net> [not found] ` <sgDUc.26532$9Y6.17585@newsread1.news.pas.earthlink.net> [not found] ` <3bOUc.46253$US4.14922@trndny01> 2004-08-19 0:37 ` Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management Richard Riehle 2004-08-19 4:54 ` Thomas G. Marshall 2004-08-19 8:10 ` Dmitry A. Kazakov 2004-08-19 16:24 ` Thomas G. Marshall 2004-08-19 12:52 ` Jim Rogers 2004-08-19 16:31 ` Thomas G. Marshall 2004-08-20 1:27 ` Stephen Leake 2004-08-20 7:00 ` Richard Riehle [not found] ` <TgfUc.122489$M95.15934@pd7tw1no> [not found] ` <XtOUc.4483$QJ3.4254@newssvr21.news.prodigy.com> 2004-08-19 0:39 ` Richard Riehle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox