Adding the exclamation point

I've written an article in response to this item: The Futility of Adding Types to a Dynamic Language

I think people overreact a bit. Static typing - at least the optional variant - is available to Common Lisp implementations for quite some time. Depending on the (speed ...) and (safety ...) settings they can be used to actually check values or to optimize code. This allows for example the compiler to optimize out boxing of numbers and to produce highly optimized numeric code - there are still people out doing number crunching ...

What _does_ bother me is that Guido totally ignores already existing concepts for interfaces (as that is one thing he is talking about as an option for optional typing) and generic functions (as that is another thing he is talking about as the use for typings - his generic types). For example there is the PyProtocols package that delivers (at least in the dev trunk) both python interfaces, automatic type adaptions and a generic functions (multi parameter dispatch) implementation.

It's rather ridiculous that he is talking about stuff that is solved in many languages before and even solved for Python but still makes all possible mental fuckups in his discussion that are possible in that field. It would be far easier to just promote PyProtocols to a standard library package and get rid of the whole discussion ...

Sure, from the Smalltalk point of view this is even more silly than from other dynamic languages, as Smalltalk is duck-typing all the way down. But multi-paradigm-languages can often benefit from optional type informations. Type inference isn't allways the easiest thing to do - for example think of a number crunching application where you only use generic numerical methods. The compiler can't infer what numerics you will use. So he has to box numeric values to attach the type informations. Give the compiler a hint on what types are used and the compiler can just put type checks in the front of the functions and optimize all he wants internally and directly work on the floating point stack of the floating point engine of the CPU.

Same with integer arithmetics and integer overflows - say you won't overflow (or if you will overflow, your application will know how to handle it) and the compiler will be able to produce much faster code. Nice for many algorithms in the graphic area.

So even dynamic languages - at least languages of a more hybrid nature than Smalltalk - can benefit from type informations. Even if they use type inference for most part of the compilation (like CMUCL is able to do - even there it helps to define types to produce optimal code).

I agree that this feature isn't as critical as people often put it in discussions, though: there are situations where you might need it, but 99% of your application will happily work without it and will work fast enough to be usefull. That's why I usually don't miss it much when working with Smalltalk or Python - I just tend not to write programs that need such optimizations in those languages (or use other tools to solve it like PyRex in Python).

As addition to the excellent comment by Georg Bauer:

As for compiling efficiently, Python has the disadvantage, compared to Common Lisp, that built-in classes are subclassable by the user, so even having both x and y declared as 'int' doesn't mean x+y can use the fast int-+ and will result in an int (or long, whatever), because x or y could be an instance of a subclass of int that overrides add. Type checks at runtime will still be needed.

But then again, Guido seems to intend this mostly for checking programs for errors statically, for which type declarations could be useful.