[erlang-questions] Runtime checking for types

[Richard O'Keefe]

On 18/04/2011, at 10:58 PM, Jesper Louis Andersen wrote:
> The initial ignorance of static types in Erlang is understandable.

Joe Armstrong and the others weren't _ignorant_ of static types;
they just didn't bother using them.  Their time was of course
limited; they had other maddened grizzly bears to stun; and there
was no suitable type system available off the shelf.

In a language like Occam or Go it is feasible to have types on
channels, because there is one program.  In a *distributed*
world, where X!Y may send Erlang term Y to a machine anywhere
in the world, there doesn't seem to be any reason why process
X should *believe* the type checker that allowed the original send.

>  Thus, I have lost *nothing* compared to Erlang, but I can
> compile processes to be an order of magnitude faster, trivially.

It is not immediately clear that this is true.
Yes, Erlang could be faster.  But you would *still* need some kind
of run time tag checking for integer arithmetic, or else sacrifice
Erlang's ability to generate correct answers (as for example Java
so cheerfully and annoyingly did).  You would *still* have to have
some kind of dynamic type checking when values are communicated
from the past to the future (for example, Dynamic in Clean has to
do this, and of course so does Java serialisation).  You would
still have to compile code in such a way that it can easily be
removed and replaced.

There *are* techniques that could be used to make a "modern"
Erlang faster, but they mostly come from other dynamic languages,
like Self (and even from dear old Spitbol).

> Remember, dynamic typing is a straitjacket, in which you cannot fully
> express yourself, whereas static typing give you a rich language for
> doing so.

This sounds very much like a crab telling humans how limited they
are by the absence of a shell.  Think of the problems of moulting.

Erlang is about building *reliable* distributed programs, not fast
ones.  In many applications it is more important to manage the flow
of messages across the network than to shave a few cycles off an add.
It is important to know that version skew won't cause fatal system
integrity problems (and yes, I *have* experienced total insanity of
a Java program due to version skew).  

The type system used by the Dialyzer, what is it?  Is it the third
type system developed for Erlang or the fourth?  Or have I missed
some?  It took *years* to figure out what a type system for Erlang
should be like, and to my mind it is still missing some major
features.  If the CSLab people had waited until they got the type
system right before releasing Erlang, we'd still be waiting.