caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "David McClain" <barabh@qwest.net>
To: <caml-list@inria.fr>
Subject: Re: [Caml-list] Dynamic vs. Static
Date: Fri, 9 Nov 2001 10:31:40 -0700	[thread overview]
Message-ID: <009101c16944$6498e980$210148bf@dylan> (raw)
In-Reply-To: <003001c1693c$6c1e3dc0$d0c201cf@XENO>

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


  reply	other threads:[~2001-11-11 10:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-09 16:34 Eric Newhuis
2001-11-09 17:31 ` David McClain [this message]
2001-11-09 18:15 ` Patrick M Doane
2001-11-09 18:31 ` Pixel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='009101c16944$6498e980$210148bf@dylan' \
    --to=barabh@qwest.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).