From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 108717,c1d77749223627c8 X-Google-Thread: 1108a1,8802fe2212b159e1 X-Google-Thread: 114809,8802fe2212b159e1 X-Google-Thread: 103376,6cd90863b65ff36b X-Google-Attributes: gid108717,gid1108a1,gid114809,gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny07.POSTED!ab059812!not-for-mail From: "Thomas G. Marshall" Newsgroups: comp.programming,comp.object,comp.lang.smalltalk,comp.lang.ada References: <40f3ceee@alpha.wvnet.edu> <19iip59qsl122$.3g3hicltra17.dlg@40tude.net> <40f5bbe1@alpha.wvnet.edu> <40f67c13@alpha.wvnet.edu> <9qTRc.61502$M95.25853@pd7tw1no> <411C5D2F.5070408@acm.org> <3bOUc.46253$US4.14922@trndny01> Subject: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: Date: Thu, 19 Aug 2004 04:54:42 GMT NNTP-Posting-Host: 151.203.193.46 X-Complaints-To: abuse@verizon.net X-Trace: trndny07 1092891282 151.203.193.46 (Thu, 19 Aug 2004 00:54:42 EDT) NNTP-Posting-Date: Thu, 19 Aug 2004 00:54:42 EDT Xref: g2news1.google.com comp.programming:8403 comp.object:5807 comp.lang.smalltalk:2537 comp.lang.ada:2835 Date: 2004-08-19T04:54:42+00:00 List-Id: Richard Riehle coughed up the following: > "Thomas G. Marshall" > wrote in > message news:3bOUc.46253$US4.14922@trndny01... >> Richard Riehle 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/