Erlang type system and static vs. dynamic types

[Russ Ross <address@hidden>]

I was reading Joe Armstrong's paper "The development of Erlang" from
ICFP '97 and noticed this interesting point when talking about the
new type system being applied to the standard libraries:

  "The type system has uncovered no errors.  The kernel libraries
   were written by Erlang "experts"--it seems that good programmers
   don't make type errors.  It will be interesting to see if this
   remains true when we start type checking code written by less
   experienced programmers."

For background, Erlang uses runtime/latent/dynamic typing.  The type
system being described was written as an (optional) extra pass that
checks code for type consistency at compile time.

I've read similar comments by Python and Lisp advocates who assert
that latent typing doesn't lead to errors that pop up late in the
game as one might expect because those just aren't the kinds of
errors that programmers tend to make in practice.  This Erlang
example seemed like a good concrete data point supporting such
claims.

One of the points static type systems promise is reduction of these
kinds of errors.  I'm one of those who likes the convenience of
latent types (strong latent types, not something like perl) but in
my gut I live in fear of getting involved in a large project where
everyone _else_ has that freedom and having to suffer as a result.
That fear is largely from working on a perl application with around
a dozen developers that became a nightmare to maintain partly
because of perl's fast-and-loose type system.  Static typing ala ML
or Haskell always seems like a good idea for large projects (which
is a common argument), but in my experience enforcing abstraction
boundaries and a good module system is far more important for a
group effort than what is happening inside a function or its
interface.

I was involved in a moderate sized Java project which actually
seemed to support the latent type side of the argument.  In
practice, Java's type system forces you to refer to objects through
Object references quite often so you effectively lose the static
type checking that the language promises, and this happens very
often when interfacing with libraries (that try to be generic) which
is exactly where I want strong guarantees the most.  It does verify
the legality of casts, though, so effectively Java becomes a
latently-typed language in common usage, particularly when using
collection classes and many other generic libraries.  The next
version of Java promises to fix this for some cases, but my point
here is that Java may actually stand as another data point in favor
of latent types, contrary to how it appears at first glance.  Our
application rarely suffered from invalid class cast exceptions, and
when it did they appeared very early (usually at system startup time
from dynamically loaded classes and configuration data) so they were
easy bugs to find and fix.

- Russ