Today, as yesterday, the issue of whether explicit/early type declarations are a Good Thing or a Bad Thing came up. Sometimes, I even saw how the discussions got a bit too personal. Besides the fact that talking about people is not going to address technical issues, the observation remains: clearly, it is a tough issue to discuss. But why? And what is it about types that causes so much grief?
I had great exchanges about this topic... and I came to the following summary that I would like to write down before going to sleep.
Overall, the issue of whether to use types or not is a matter of which values you want to emphasize. Do you care about preventing errors from occurring at run time? Do you care about cost of change?
When I work with Smalltalk, I think mostly about the problem at hand because Smalltalk has this tendency to become a mirror for my thoughts. As I put more stuff into it, I get feedback that I can apply to converge to the solution I am looking after more quickly.
As with numerical integration of differential equations, the key here is the size of each integration step. Shorter feedback cycles will lead to better overall results because they allow more fine adjustments to occur more frequently. And since finding a valuable solution to pretty much any problem more difficult than a CS homework assignment requires a Serious Amount of Thought, I think it is a good idea to make the feedback cycle lag as short as possible.
Immediately, this implies that an explicit type system is detrimental. I only have 7 plus minus 2 slots in my mind's scratch ram, and the more I need them for thinking about things other than my problem is going to cause me grief. If I need to swap out parts of my problem to think about explicit type declarations, then I am going to spend time and energy
- thinking about the problem of specifying explicit types, which also comes with rules and process to follow etc, and
- forgetting and remembering how I was thinking about my actual problem,
Since I only have so much time to achieve my goals, I'd rather spend time with my problems rather than with manual tools for finding simple errors. In particular, since explicit type tools are typically associated with "write-compile-run-crash-post mortem debug" programming cycles, my feedback cycles would be much more longer. This will inevitably lead to decreased solution accuracy, or at best, to increased energy expenditure to obtain an equivalent result.
Plus, of course, type systems do not let us fix problems in an execution context, thus making us imagine how things would break instead of seeing the actual bug in action. And we know how wrong we can be when we imagine things. So it seems to me that debugging in a debugger is more valuable.
Therefore, if we are to get value out of a type system, it must be of the kind that does not cause us additional work when we are writing actual code --- such as in the form of a button that we press when we so desire.
But good type inference engines are hard to come by. So instead of writing a better tool, let's cause tolerable manual work for the developers and use type annotations instead. In other words, you write your code first, then you annotate and run a type checker.
And it seems like an ok thing to do. You do not pay when you write the code, and whatever amount you pay seems reasonably bounded. Until, of course, comes change and new version 2.0 requirements. The moment you start changing the code again, all those type annotations become invalid. So now you have two options.
- Maintain type annotations as you change code... but that gets you into the situation where your actual development process is hindered with productivity taxes, or...
- Forget about the type annotations until you are about to release, then fix them all.
So, in conclusion, a type system that provides actual value to developers must
- be non intrusive with respect to developer work, and
- not need manual maintenance from developers.
Thus, given the following two options,
- A mandatory, early declaration type system, or
- No type system at all,
I simply cannot waste time working on anything else than my problems. I only have one life to find elegant solutions to problems. I do not need to think about blame. I do not need to think about shame. I do not need something to tell me I didn't comply. I need something that helps me be more creative. Mandatory type systems do not help neither bring overall value to this endeavor.
Now, for the times when I really want a safety net, I'd rather write a framework that lets me express what those safety nets are. This, of course, is also covered in my book.