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 RAA19809; Fri, 9 Nov 2001 17:35:52 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA19476 for ; Fri, 9 Nov 2001 17:35:51 +0100 (MET) Received: from c0mailgw08.prontomail.com ([216.163.180.10]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fA9GZo512825 for ; Fri, 9 Nov 2001 17:35:51 +0100 (MET) Received: by c0mailgw08.prontomail.com (NPlex 5.5.029) id 3BD61043002D6BA0 for caml-list@pauillac.inria.fr; Fri, 9 Nov 2001 08:29:00 -0800 Received: from 207.1.194.208 by SmtpServer for ; Fri, 09 Nov 2001 16:29:00 +0000 X-Sender: 29538.starband.net Message-ID: <003001c1693c$6c1e3dc0$d0c201cf@XENO> Reply-To: "Eric Newhuis" From: "Eric Newhuis" To: "Caml" Subject: [Caml-list] Dynamic vs. Static Date: Fri, 9 Nov 2001 10:34:36 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C1690A.20D405C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C1690A.20D405C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would anyone care to read this and comment on it w.r.t. Caml/ML/etc? http://wiki.cs.uiuc.edu/VisualWorks/Mark+Fussell+Dynamic-vs-Static+Typing= +Message ------=_NextPart_000_002D_01C1690A.20D405C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Would anyone care to read this and = comment on it=20 w.r.t. Caml/ML/etc?

http://wiki.cs.uiuc.edu/VisualWorks/Mark+Fussell+Dynami= c-vs-Static+Typing+Message

------=_NextPart_000_002D_01C1690A.20D405C0-- ------------------- 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 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 TAA22918; Fri, 9 Nov 2001 19:15:32 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA16305 for ; Fri, 9 Nov 2001 19:15:30 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fA9IFT514493 for ; Fri, 9 Nov 2001 19:15:30 +0100 (MET) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.6/8.11.5) with ESMTP id fA9IFAN84373; Fri, 9 Nov 2001 13:15:15 -0500 (EST) (envelope-from patrick@watson.org) Date: Fri, 9 Nov 2001 13:15:09 -0500 (EST) From: Patrick M Doane To: Eric Newhuis cc: Caml Subject: Re: [Caml-list] Dynamic vs. Static In-Reply-To: <003001c1693c$6c1e3dc0$d0c201cf@XENO> Message-ID: <20011109130158.O80907-100000@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk The compelling argument to me in this paper is the example regarding collections and Java. The type for the method public boolean AbstractCollection::removeAll(Collection c) is obviously too restrictive. The argument in favor of it was to reduce the number of interfaces in the standard library. There is good reason for limiting this in Java because subtyping is directly related to inheritance. To introduce a new interface would require figuring out how to compose all of these pieces together. Caml doesn't suffer from this particular problem because subtyping is not related to inheritance. It would be trivial to create a new class type that is used in various type signatures that specify exactly the set of methods that are required. C++ templates have a similar kind of freedom in that the types in that the types needed to compile a function are inferred directly from the definition of that function. The problem with a system like C++ and also with the dynamic approach (as far as I know - please correct me if this is wrong) is that there are times when it is useful to constrain a type by more than what is required for a particular implementation. I've seen several cases of STL container objects in C++ that work for one implementation of the standard algorithms but fail to work with a different implementation. Now the author had made a mistake with respect to the documentation, although everything was legal from the compiler's viewpoint. It's also worth noting that, for whatever reason, Caml does not have a very good collection library. The modules indivually are quite good but they lack the unification that allows a developer to easily plug in a new implementation as needed. Patrick On Fri, 9 Nov 2001, Eric Newhuis wrote: > Would anyone care to read this and comment on it w.r.t. Caml/ML/etc? > > http://wiki.cs.uiuc.edu/VisualWorks/Mark+Fussell+Dynamic-vs-Static+Typing+Message > > ------------------- 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 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 TAA23015; Fri, 9 Nov 2001 19:33:59 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 TAA23675 for ; Fri, 9 Nov 2001 19:33:58 +0100 (MET) Received: from leia.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fA9IXwn24357 for ; Fri, 9 Nov 2001 19:33:58 +0100 (MET) Received: by leia.mandrakesoft.com (Postfix, from userid 505) id 3AF8C578F; Fri, 9 Nov 2001 19:31:30 +0100 (CET) To: "Eric Newhuis" Cc: "Caml" Subject: Re: [Caml-list] Dynamic vs. Static References: <003001c1693c$6c1e3dc0$d0c201cf@XENO> From: Pixel Date: 09 Nov 2001 19:31:29 +0100 In-Reply-To: <003001c1693c$6c1e3dc0$d0c201cf@XENO> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk "Eric Newhuis" writes: > Would anyone care to read this and comment on it w.r.t. Caml/ML/etc? > > http://wiki.cs.uiuc.edu/VisualWorks/Mark+Fussell+Dynamic-vs-Static+Typing+Message this is quite old, hopefully this guy doesn't ignore MLs anymore :) in short, the guy is defending Smalltalk against Java and more generally dynamic typing vs static typing (but he only knows Eiffel Java C++) some comments > (C) Precise type information is lost when objects are fed through more generic structures. this one is clearly obsolete, even java 1.4 will fix the lack of parametric polymorphism (C++ has templates) > And the argument can be more informed than just personal opinion. We have plenty of examples of the > various languages to compare[1]]: The libraries of Smalltalk, C++, Perl, Java, Eiffel, etc.; Design > Patterns in various languages; and so on. If you review all these languages in depth you will find > that static typing is certainly harming scalability. i agree that the best basic libraries (including simple things like Collections, Dictionnaries, Strings...) i ever found were in dynamic languages (/me thinking of ruby). But I think the main pb is that few languages do really care about them. Of course, Java has the big no parametric polymorphism which harms a lot its basic libraries (which looks a lot like dynamically typed libraries) > It may be helping in certain ways against mistakes in the small, hum, the idea behind static typing is more helping catching mistakes in the big... where someone can't think of everything (just like someone can handle memory management in some small programs, but it gets much harder in bigger progs) > but it is interfering with good code (code that will execute properly at > runtime, is easy to understand, is easy to maintain, and is useful to many clients) that helps grow > systems in the large and over time. - "execute properly" is the static typing strength so i don't understand - IMO "easy to maintain" is nonsense together with dynamic typing. Maybe "easy to extend" (as he's saying somewhere else) is something that can be true in some cases (eurk, i've been using runtime re-parenting of perl classes so i know what i'm talking about :) > (B) Types have poor granularity. Frequently a Type will be specified that has too many operations (is > too specific) to be useful in multiple contexts even though subsets of those operations (a more > general concept) is widely useful. Since it costs effort to name and create each Type, there is an > impetus of reduction that again impedes reuse and generalization. Save now, pay later. objects in OCaml are very flexible (too much?) and enable things only dynamically typed languages achieve: ******************************************************************************** (* 2 unrelated classes used polymorphically based on the same methods *) let work_on_x o = o#get_x + 1 (* work_on_x : < get_x : int; .. > -> int *) class class1 = object val mutable x = 0 val mutable y = 0 method get_x = x method get_y = y end class class2 = object val mutable x = 0 val mutable z = 0 method get_x = x method get_z = z end let o1 = new class1 let o2 = new class2 ;; work_on_x o1, work_on_x o2 ;; ******************************************************************************** of course, there are limitations: some people may find this a little bothering: List.map work_on_x [ (o1 :> ) ; (o2 :> ) ];; -- Pixel programming languages addict http://www.chez.com/prigaux/language-study/ ------------------- 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 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