This note is a small aside on the discussion about strictly dynamic systems,
and Smalltalk in particular...

I have had the most interesting experience during this past year of being
the consumer "user" of a large multi-DSP system written at the top level in
Smalltalk. I cannot vouch for the programming expertise demonstrated by the
producers of this product. But I can say that Smalltalk appears to suffer
tremendously from small perturbations in the code. Every time some new
feature is announced in an upgrade, numerous other features break.

Surely, the lack of explicit tight typing contributes to this, as otherwise
these changes would be seen at compile time to break other portions of the
code. My impression, based also on my own Smalltalk programming experience
over the last 20 years, is that while apparently flexible in concept, the
characteristics of Smalltalk that cause little definitions to be scattered
all over the place makes it ultimately difficult to predict the effects of
code changes. One is forced to understand all of the system in order to
understand how changes will ripple through the code.

I also think that the producers of this product fail to properly modify the
code through subclassing. I would think that proper subclassing would
prevent the breakage of existing routines, but without seeing the source I
cannot vouch for whether the vendor does or does not approach things in this
way.

Smalltalk, Lisp, RSI/IDL, and many other dynamically typed systems all
suffer the possibility of unforseen failures in released code, much more so
than something like OCaml, SML, or Haskell. All systems are subject to
weaknesses of the underlying OS. But failure to check every branch of a
program at compile time is surely a problem in the most dynamically typed
languages.

I strongly enjoy Lisp programming as the "ultimate modeling clay". But for
production-like code, I wouldn't dare use anything other than OCaml. [This
is not to slight SML and Haskell - I just find OCaml easiest to use all
around especially since most of my code uses serious amounts of interfacing
to foreign code].

I have always enjoyed playing with the browsers of Smalltalk, and I often
wish for similar features in other language environments, including Lisp.
But pleasure aside, the robustness of Smalltalk environments is
questionable, at least in my mind. I don't know if converting from Smalltalk
to Lisp would improve the situation - it might. CLOS is a very powerful OO
system, especially given the MOP. But nevertheless, it remains dynamically
typed, and this can result in downstream failures that could easily have
been avoided with something like OCaml's typing at compile time. The defense
against such errors requires explicit type checking code in Lisp, and this
tends to clutter the source dramatically. At that point it is more succinct
to program in OCaml.

Just my 2c's....

- David McClain
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr