Re: [Caml-list] Dynamic vs. Static

[Pixel <pixel@mandrakesoft.com>]

"Eric Newhuis" <enew@bigfoot.com> 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 :> <get_x: int>) ; (o2 :> <get_x: int>) ];;

--
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