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!wn13feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.programming,comp.object,comp.lang.smalltalk,comp.lang.ada Subject: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management From: Jim Rogers 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> Organization: Your Company Message-ID: User-Agent: Xnews/5.04.25 Date: Thu, 19 Aug 2004 12:52:55 GMT NNTP-Posting-Host: 12.73.183.37 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1092919975 12.73.183.37 (Thu, 19 Aug 2004 12:52:55 GMT) NNTP-Posting-Date: Thu, 19 Aug 2004 12:52:55 GMT Xref: g2news1.google.com comp.programming:8420 comp.object:5839 comp.lang.smalltalk:2563 comp.lang.ada:2850 Date: 2004-08-19T12:52:55+00:00 List-Id: "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. Jim Rogers