[Caml-list] Dynamic vs. Static

[Caml-list] Dynamic vs. Static

[Eric Newhuis]

[-- Attachment #1: Type: text/plain, Size: 157 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 703 bytes --]

Re: [Caml-list] Dynamic vs. Static

[David McClain]

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

Re: [Caml-list] Dynamic vs. Static

[Patrick M Doane]

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

Re: [Caml-list] Dynamic vs. Static

[Pixel]

"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