[E-Lang] required type annotations lead to more integration b ugs (was: ...)
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), and read _Extreme_
_Programming_Explained_ by Kent Beck.
>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.
 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.
 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.