Until not so long ago, still an ignorant geek, I was a forthright proponent of strong or static typing. How often have I scoffed at JavaScript, VBScript, PHP and other dynamic languages and their apparent lack of typing. And how glad was I to switch from a classical ASP project to a C# .Net project; finally, the wonders of static typing would help me write better code once again.
Now, a great deal of object awareness later I’m seriously in doubt wether static typing is really helping me to write “better” code. The only thing that’s really different with, say some of my old JavaScript code is the fact that I have to write a lot of explicit casting to mold each instance into it’s appropriate shape. Wondering about types, performance and memory is a frequent occurence. Heck, we even seem to be discussing in bits, bytes and words and worrying about a type’s length on a regular basis when there’s one of those interresting “which sort of integer will it be” questions.
Failing to think up any clear code examples I’m calling in the words of Peter William Lount (strongly recommended read) talking about the dynamic alternative to strong typing as implemented in Smalltalk:
A reason that Smalltalk applications hold together is that the objects carry their “type information” with them as they travel through the program. This means that variables are free to hold ANY object at any time which provides the basis for “dynamic freedom”. Any “constraints” that need to be applied to restrict the “class” of objects that can be assigned to a variable are done at runtime using the full semantic power of the Smalltalk language rather than a limited “static type syntax”.
Below is his view on “static” or, maybe more appropriately, “enforced” typing:
When you apply limited – single or even multiple – “static” type specifications (either manually entering them or via type inference) to variables the possible pathways for information and objects to travel within the program is severly restricted. This reduction is a loss of degrees of freedom of movement for the program and the designer. Maybe that’s what you want, but more often than not it simply limits what you can write. This is why applying constraints to variables is less than desireable and should be applied with caution and the awareness of future limitations in the program.
Almost all typing errors the compiler catches must be resolved with a cast and we can only conclude our intentions are correct if the only thing missing is one specific word, a casting instruction that’s (even statically) implicit anyway. This means that we maybe really don’t actually need the “safety net” the compiler supposedly provides. At least not to help us create “better” code.