Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management

[Jim Rogers <jimmaureenrogers@worldnet.att.net>]

"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