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

["Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com>]

Jim Rogers <jimmaureenrogers@worldnet.att.net> coughed up the following:
> "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.

{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:

<quotezilla>
    1) Complicated model
    2) Incorrect types ("ever so slightly off the mark
    3) Difficult to discover
    4) Laborious to fix
</quotezilla>

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/.