From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA11201; Sun, 11 Nov 2001 11:59:05 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA11459 for caml-list@pauillac.inria.fr; Sun, 11 Nov 2001 11:59:04 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA20146 for ; Fri, 9 Nov 2001 18:31:29 +0100 (MET) Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id fA9HVRn22760 for ; Fri, 9 Nov 2001 18:31:28 +0100 (MET) Received: (qmail 97231 invoked by uid 50); 9 Nov 2001 17:31:25 -0000 Delivered-To: fixup-caml-list@inria.fr@fixme Received: (qmail 97099 invoked by uid 0); 9 Nov 2001 17:31:23 -0000 Received: from adslppp97.tcsn.uswest.net (HELO dylan) (216.161.144.97) by tcsnpop1.tcsn.uswest.net with SMTP; 9 Nov 2001 17:31:23 -0000 Message-ID: <009101c16944$6498e980$210148bf@dylan> From: "David McClain" To: References: <003001c1693c$6c1e3dc0$d0c201cf@XENO> Subject: Re: [Caml-list] Dynamic vs. Static Date: Fri, 9 Nov 2001 10:31:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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