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!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Dmitry A. Kazakov" 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 Date: Thu, 19 Aug 2004 10:10:58 +0200 Message-ID: <40cmn8qnj5kv$.1llvajtdbf755.dlg@40tude.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de oOpDrStOpmaaRxjS6r2aMAyPqCRL8/hE0/Z7fSZlfD26y1b0A= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.programming:8416 comp.object:5829 comp.lang.smalltalk:2551 comp.lang.ada:2844 Date: 2004-08-19T10:10:58+02:00 List-Id: 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