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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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