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 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 16:31:06 GMT NNTP-Posting-Host: 151.203.224.68 X-Complaints-To: abuse@verizon.net X-Trace: trndny07 1092933066 151.203.224.68 (Thu, 19 Aug 2004 12:31:06 EDT) NNTP-Posting-Date: Thu, 19 Aug 2004 12:31:06 EDT Xref: g2news1.google.com comp.programming:8436 comp.object:5850 comp.lang.smalltalk:2571 comp.lang.ada:2860 Date: 2004-08-19T16:31:06+00:00 List-Id: Jim Rogers coughed up the following: > "Thomas G. Marshall" > 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: 1) Complicated model 2) Incorrect types ("ever so slightly off the mark 3) Difficult to discover 4) Laborious to fix 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/.