[E-Lang] required type annotations lead to more integration b ugs (was: ...)

zooko@zooko.com zooko@zooko.com
Sat, 03 Mar 2001 13:52:39 -0800

 Alan Karp wrote:

> I actually found I can prototype faster with strict typing because the
> compiler always tells me where the problems is.  (Static type checkers are
> fine, too.)  That's why I like my trick of controlling at compile time what
> type can go into a collection rather than a run-time check on what comes
> out.  Run time debugging requires me to track backwards from where the error
> was noticed to where it was introduced.  In many situations, such as
> computing statistics on collections, you don't even get an exception, just a
> wrong answer.  Wrong answers are the worst bugs of all (except for security
> bugs, of course.)

[Note: the following article isn't about type systems, it is about
marketing in the form of hurdle number #3: usability for learning and
for small projects.]

I was a strong "static typing" advocate and practitioner until about 
12 months ago when I started with Evil Geniuses, started my first
large-scale project in Python (Mojo Nation[1]), and read _Extreme_
_Programming_Explained_ by Kent Beck[2].  

>From working on Mojo Nation with a team (including me) of three, then
four, then five, then six other coders, I have come to greatly
appreciate Python's dynamic structural typing.

So my opinion, based on my experience plus some inference about other
possibilities, is that static typing actually *does* speed up early
prototyping, but not if it is combined with required type annotations
(see a message about optional vs. required type annotations that I just

It is also my opinion that structural rather than nominative typing is
better for rapid prototyping, and my ideal typing system would allow
for smooth transition between un-annotated to annotated, structural to
named, and dynamic to static (except that I do want static typing
during prototyping, but only if it is structural and has
optional-not-required type annotations).

Wait -- what does this have to do with marketing?

Oh yeah, it's just that I agree with Alan that static typing is
actually a boon to rapid-prototyping, but only certain kinds of static
typing.  And having nice rapid prototyping is essential, in my mind, to
passing hurdle #3, as well as a great value in its own right.



[1]  MN might be the biggest or the second biggest open source Python
app in the world.  The other candidate is Zope.  Or maybe MN isn't even
in the top 2 -- I dunno.

[2]  The worst thing about "Extreme Programming" is the name.  I
ignored the idea for at least a year because I figured that anything
with such a stupid name must be stupid.  I was wrong.  I haven't looked
into "Extreme Programming" except for reading that one book, but I
highly recommend that book both to coders and to E language designers.
It is a very fast, fun, easy read, and it clearly shows a kind of
programming (not just a style of coding, but a kind of programming as a
social and creative activity) that will be widespread in E.