The Type War, Misunderstanding, and Pragmatism
Summary: Static types are back, but most programmers are hesitant to leave their comfort zones and think holistically.
The Type War
The dynamic devotees deify rapid development time, while the the static supporters seek correctness and performance.
Will this war ever resolve? Will it cycle forever like the battle between good and evil? Let’s take a look at the latest chapter to form our own opinion.
The Pendulum Has Swung
At different times in computing, static and dynamic typing have traded off the honor of being the dominant paradigm of the day.
Through the dot-com boom and for several years afterward, dynamic languages dominated during the growth of the Web, from Perl-CGI through PHP, ASP, and then the emergence of Ruby on Rails.
The pendulum has now begun to swing in the opposite direction, perhaps beginning with Twitter’s famous migration from Ruby to Scala, lending new credibility to functional programming and static typing.
These days, it seems that more and more programmers, whether members of the static or dynamic camp, agree that, “Yes, types are helpful for correctness, documentation, and refactoring.”
On the one hand, it’s great to see this well of strongly-typed enthusiasm leading to the mainstream success of languages like Rust, which embraces esoteric ideas from type theory! This would have been unthinkable only a few years ago.
On the other hand, it seems that some of this enthusiasm is misplaced or confused, and I’d like to untangle some misunderstanding that I perceive in industry right now.
However, what most bums me out is that, like occurs with many popular movements, there seems to be a cargo cult forming, that is, programmers / technical decision makers are failing to take into account how a language works as a comprehensive whole and losing the problem-solving forest for the statically-typed trees.
Adopting static typing may be beneficial for aiding in correctness, documentation, and refactoring, but what tradeoffs do you make in so doing? And is TypeScript the best way to get there?
What saddens me is that there are great, self-consistent languages that sit in the same niche as TypeScript and Flow that are largely being ignored.
In all three cases, we’d be picking up a more powerful, less bug-prone, terse language.
Surely I’m not the only one that finds it ironic that these diehard TypeScript fans who extol the virtues of static typing aren’t actually willing to reach all the way towards the tools that will maximize leverage of their brainpower?
Worse is Better
On the other hand, does the industry ever gravitate towards cohesive, decisive, polarizing options? No. As we’ve learned from Steve Yegge, the moderate/centrist language generally beats out the ones at both poles. Hence the success of Java and C# over the last 20 years, C++ in the 1980s and 1990s, and C in the 1970s.
In each case, there was a credible, forward-thinking option available, but it was too scary! Too different! Much more comfortable to something only incrementally different than the current tool: from assembly programming to C, from C to C++, from C++ to Java.
Also, I should point out that, in each case there was ONE key “tick-the-box” feature that drove the migration.
- From assembly to C: assembly is great, but machine-specific. Oh, C is portable assembly? I’m in!
- From C to C++: man, object-oriented programming sounds great, but I don’t want to learn Smalltalk or Eiffel! OK, let’s add objects to C and call it C++.
- From C++ to Java: garbage collection could make us more productive and eliminate a whole class of errors! Java is C++ with garbage collection? Sold!
Yes, you could move to PureScript or Elm (or Clojurescript), and even enjoying seamless interoperability with your legacy code through your entire migration, you’d still have to re-train your developers in a new paradigm, I get it.
Politics, not principles. Easy, not simple.
But perhaps I need to have more empathy and patience? Jeff Atwood reminds us that there are Two Types of Programmers, and that the pace of change among the 80% is glacially slow.
The message that I hope to impart, however, is that these issues are never as simple as black and white.
Static typing has benefits, yes, but there are also tradeoffs. But, as we see time and again, “Programmers know the benefits of everything and the tradeoffs of nothing.”
My ask for you is to remind yourself to examine these tradeoffs closely and make the right decisions for your problem domain.
Remember, if static typing were the silver bullet, there’d be no reason to use Clojure over Haskell.
And yet, even a Haskell devotee confesses, “Haskell seems like a particularly good fit for software where correctness and quality matter. You might expect to pay for its safety in reduced iteration speed.”
Before you get out your pitchfork, remember this is not a rallying cry for dynamic languages.
This is a stand for well-reasoned decision making. No groupthink, no cargo cult, no “tick-the-box.”
David Kay has dedicated his life to the advancement of the technological singularity. He is a serial entrepreneur, working to impact the future of software development and medicine. If you found this article helpful, join his weekly newsletter.