I really enjoy static (manifest) typing. This might surprise those familiar with my previous writings, but it’s the truth. I genuinely feel more at ease with code like MPWType1FontInterper *interpreter than id interpreter. Considerably more at ease, actually, and this sentiment is reinforced when Xcode declares “0 warnings” and the clang static analyzer concurs.
Safety
The question, however, is: are these feelings actually justified? The discourse surrounding this topic is undoubtedly intense and often quite rigid and absolute. Recently, a Computer Science Professor asserted unequivocally that any programmer not using static typing should be stripped of their degree. This happened in a room full of Squeakers. And this isn’t some outlandish, isolated incident. Almost every discussion on the topic seems to quickly escalate into proponents of static typing making definitive claims that dynamic typing inevitably results in buggy software riddled with crashes in production, while statically typed programs have their bugs neatly caught by the compiler and are, as a result, secure and stable. In fact, Milner supposedly once declared that “well-typed programs cannot go wrong”. Hmm…
It’s undeniable that the compiler, using static type checks, is capable of catching a certain subset of bugs. However, it’s equally evident that type errors don’t encompass all possible bugs. For example, the majority of the 25 top software errors don’t strike me as type errors, and neither the infamous “goto fail” nor the Heartbleed vulnerability seem like type errors either. Similarly, the most common errors in my various projects aren’t related to typing. Having a type-checker give our programs a clean bill of health doesn’t magically make them bug-free; it merely eliminates a specific category or type of bugs.
With this understanding, we can shift the conversation from fervent dogma to reasoned investigation: how many bugs does static type checking actually prevent?
Unfortunately, this isn’t a simple question to answer because we’re searching for something that’s inherently absent. But we can reframe the question: what’s the occurrence rate of type errors in dynamically typed programs, those lacking the bug-catching safety net of a static type system and therefore theoretically more prone to these errors?
With the rise of publicly accessible source code repositories, we now have a means of exploring this question, and Robert Smallshire did precisely that, conducting grunt work and arriving at an answer: 2%.
The 2%
He delves deeper into this topic in his talk titled The Unreasonable Effectiveness of Dynamic Typing, which I highly recommend. However, this isn’t the sole source of information. For instance, a study titled An experiment about static and dynamic type systems: doubts about the positive impact of static type systems on development time (pdf) found that, on average, not only were development times noticeably quicker with dynamically typed languages, but so were debugging times.
This suggests that all those supposedly abundant type errors weren’t actually hindering debugging efforts; in fact, the opposite was observed. This finding makes sense if the incidence of type errors is indeed in the vicinity of 2%, as other factors then become far more likely to dominate the development and debugging process. Completely.
There are additional studies available, such as one focusing on generics: Do developers benefit from generic types?: an empirical comparison of generic and raw types in java. The researchers involved discovered a documentation benefit but no discernible error-fixing benefits and, notably, a negative impact on code extensibility.
Others have articulated this point more eloquently than I ever could:
Some individuals are utterly devout about type systems, and as a mathematician, I appreciate the concept. However, nobody has managed to devise one with sufficient scope. If you were to combine Simula and Lisp—Lisp lacked traditional data structures, instead utilizing object instances—you’d have a dynamic type system offering the expressive power you need.
Even staunch advocates of strong typing like Uncle Bob Martin, with whom I’ve had numerous spirited debates on this and other matters in the realm of object-oriented programming, have come to acknowledge this perspective: yes, static typing is nice, maybe, but it’s not the be-all and end-all. In fact, he has publicly reversed his previous stance, as evident in this video of him debating static typing with Chad Fowler.
Truthiness and Safyness
What I find intriguing isn’t so much the question of which side is right, wrong, better, or whatever, but rather the striking contrast between the fervor of the rhetoric, at least from one side of the debate (“revoke degrees!”, “can’t go wrong!”), and both the utter lack of empirical support for these claims (with some evidence actually contradicting them) and the relatively minor magnitude of the effect being discussed.
Stephen Colbert coined the term “truthiness” to describe “a ’truth’ that someone presenting an argument or making an assertion believes they know intuitively, ‘from the gut’ or because it ‘feels right,’ without regard for evidence, logic, intellectual scrutiny, or actual facts.” [Wikipedia]
It seems to me that a similar phenomenon is at play here: as I observe in myself, it just feels so much safer when the computer assures you that there are no type errors present. Especially when considerable effort is required to achieve that state, which it often is. As I mentioned, I recognize this tendency in myself, even though I’m aware that the supporting evidence is lacking, and I’ve long considered myself an amicable skeptic.
So, it appears that static typing possesses an aura of “safyness”: people simply know in their gut that it must be safe, regardless of what the evidence suggests. And this makes the debate both intensely passionate and nearly impossible to resolve rationally, mirroring the political discourse surrounding other “truth” issues.