Re: Erlang type system and static vs. dynamic types

["andrew cooke" <address@hidden>]

I guess people have grown a little tired of static v dynamic debates, but
here are a couple of observations related to your comments about Generic
Java (Java 1.5 preview), which I've been using recently.

While I didn't notice it help catch any extra errors in new
collections-related code (following your arguments), it was useful in two
ways.  First, as a notation, it helped clarify a class hierarchy I was
working on.  This is the kind of thing that more disciplined / better
educated programmers would already have used, but for those as lazy as I
am having the notation within the language is a useful convenience feature
 (tying in with anecdotes - possibly misguided and, at least in this mail,
completely unsubstantiated - about the explicit notation of static typing
encouraging higher order functions; in Generic Java's case the notation is
so ugly and verbose that you avoid anything more than two nested levels of
declarations, but then it isn't trying to be a functional programming
language).

Second, it helped when refactoring code.  Adding an extra level of
indirection to container related code (moving from containers of objects
to containers of containers) was very easy - related code didn't compile
until the signatures changed, making it easy to identify affected code. 
This is just an extension of the related argument that static typing can
play the role of some testing during refactoring.

Andrew

Russ Ross said:
[...]
> 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.

-- 
http://www.acooke.org/andrew