Re: Static/Dynamic typing, lessons from the field

André Thieme wrote: 
Hmm, don't know what to think about this article.
The author says:
"They artifically limit your expressiveness."

And his justification is an example:

"In Java, for instance, the type system doesn't let you do operator
overloading, multiple inheritance, mix-ins, reference parameters, or
first-class functions. Any time the most natural design involves these
things, you're stuck trying to mutate it into a design that fits Java's
type system."

But what does static typing have to do with Javas non-existing support
for the points he mentioned (operator overloading, mult. inh., etc.)?
The Java designers did intentionally *not* putting them into the
language. From Suns point of view that might be a good thing cause Java
is now pretty much the most popular programming language.
The author got that point plain wrong.

It's actually true that whenever you try to design new language features for Java, you always have to match them against Java's type system if you want a remote chance that it will ever get accepted. And this can lead to horrible situations. Consider the interactions between AspectJ 5 and generic types in JDK 5.

In Common Lisp, for example, it is actually relatively straightforward to create an incompatible new "world" in which your type system behaves very differently from the CL's original type system. Consider ACL2 and Qi as examples. Something like that wouldn't be acceptable in Java. (That's a social restriction, not a strict technical one.)

The relationship to expressivity is unclear here, but it is actually an acknowledged fact that static type systems have to limit the expressivity of the base language in the sense that they have to reject programs that wouldn't produce type errors at runtime. This is because there is always a grey area for which a static type checker cannot decide whether a program will produce a type error or not, and a static type system is only accepted (again socially by the people who are into static type systems) when such programs are effectively rejected.

As a comparison, CMUCL's and SBCL's compiler use a type inferencing, which means that they effectively have a static type system. But instead of rejecting programs for which they cannot prove type safety, they will just issue warnings. This is typically not considered "strong" enough.

Later he says: "Dynamic languages give you more expressive power and
more design options;" but does not explain this point. It sounds like
an opinion and therefor is not much more worth than the opinion "Static
languages give you more expressive power and more design options;".
And I personally would like to know what a static language or a dynamic
language is. Probably he wanted to say "statically typed language".
Making this kind of mistake tells me that he is probably not an expert
on this issue, and so I should not take his conclusions too serious.

It's relatively straightforward to produce example that show how a dynamically typed language can be more expressive than a statically typed one. For example, in Common Lisp you can change class definitions at runtime. Especially when you remove slots from a class, this results in a program that a static type checker wouldn't have accepted in the general case. Yet, Common Lisp provides enough rope to ensure that such a program still works (ultimately by error handlers that can take advantage of useful restarts).

There are also cases where static type systems are more expressive than dynamically typed languages, but in that case the gained expressivity is not at the base language level, but rather at the type system level. I have only seen one example so far, though, in which code can be dispatched on the type of the expected return value - which is interesting because the dispatch can depend on some future event, something that is, as far as I can tell, impossible to do in a dynamically typed language.


Pascal

--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
.

Relevant Pages

  • Re: More static type fun.
    ... Static type systems cannot prove the absence of "certain erroneous ... - You would certainly need to adapt the programming style in some ... non-trivial ways according to the actual type system you would use. ... language syntax, the set of tools you use - compilers, debuggers, and so ...
    (comp.lang.lisp)
  • Re: properties a language need to permit clean OOP
    ... needs absolutely to be an "OOP language"? ... A type system with sets of types and objects of the closures of. ... Once it comes to translating an OO design into ...
    (comp.object)
  • Re: Obstacles for Tcl/Tk commercial application development ?
    ... language, if variable X is declared as integer it will remain so forever ... Yeah, well, I figured if you fail at some point, you better be able to recover. ... A sane type system would prevent this. ... may fail because some caller is passing something that are not numbers. ...
    (comp.lang.tcl)
  • Re: How come Ada isnt more popular?
    ... A language with a Hinldey-Milner type system ... fixed size strings, unbounded strings, suffix tree. ... container varies, the element does not. ...
    (comp.lang.ada)
  • Re: Functional programming books for practitioners?
    ... Try expressing that kind of stuff even with Haskell's or SML's type system. ... If you follow that path to its logical end, you'll get a separate type for each precondition and postcondition in the system, which is clearly unmanageable. ... So you have to draw the line somewhere - what goes into types, and what goes into assertions. ... this includes a language where the type system has the full power of reasoning over integers. ...
    (comp.lang.functional)