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