Lex Spoon wrote an excellent piece in cls on the static/dynamic conflict:
I just had the culture shock of defending a Smalltalk-based research
proposal to a group of professors who love static types. It was wierd
that they really don't grok the way a "language" like Smalltalk works.
That's not my point, however.
After some reflection and some discussion with my advisor, an
interesting way to cross the gap came up: focus on the special
*environment* that Smalltalk has.
The fact is, pretty much all static type systems around only work in
systems where you every code change is followed by a re-compile and a
re-start. In this kind of scenario, a type checker can start from
scratch and just say "yay" or "nay". If it says "nay", the
presumption is that the programmer edits the program and resubmits it.
It is considered acceptible in such an environment to adamantly
require entire programs to be type safe before they are executed or
otherwise processed, and it's considered acceptible to have to
recreate all of your in-memory data whenever there is a code change.
In an environment like Smalltalk, the bulk input and the frequent data
recration both go away. Instead, programmers make one or two changes
and then run their code some more to see how it is faring. They'll
even reuse existing instances to try their changes with. TO DATE,
THERE IS NO STATIC TYPING SYSTEM WHICH FUNCTIONS IN SUCH AN
ENVIRONMENT.
The hardest issue for such a type system would be to deal with
existing data: if you have live objects floating around, then changes
to their classes will make those instances become non-type-safe. This
problem is pretty much the same as "database scheme evulation", a
difficult problem that has received a lot of attention in research. A
second difficult issue is that it may require multiple changes to
reach a new type-safe program for a simplistic type system. Somehow
the system *must* deal with the intermediate stages between type-safe
programs, in order to maintain the nice environment. Again, this is
clearly a very difficult problem. (Well, clearly if you've used
Smalltalk.)
By focussing on the environment style, the points are very clearcut
and thus the discussion is much calmer than is usual with this topic.
The debate boils down to a choice of environment style: is it
acceptible to do batch inputs instead of developing a program with
live data floating around?
This is not to say that other issues in the dynamic/static typing
debate are no longer interesting. For example, it's still true that
there aren't any good OO type systems, and it's still true that for
most practical purposes static types don't buy you very much. But in
addition to being more diplomatic, the focus on environment style
really gets at why *I* at least don't want to use static types: with
today's typing technology, static typing means giving up some of the
best features of Smalltalk. In fact, if there were a type system that
would let me work in Smalltalk as usual, then I for one would be okay
using it. I even wish there were more researchers focussing on static
typing for such environments! My issue is simply that, there is no
static type system at all that functions in a Smalltalk-like
environment.
Now, we just need a spiffy name for this style of environment....
