You know that sinking feeling when a JavaScript runtime error pops up in production? The one that TypeScript would have caught before you even saved the file? That’s not just a bug—it’s a failure of expressiveness.
We’ve been sold a lie: that the best languages let you say anything, any way you want. That flexibility equals power. That restricting yourself is for amateurs. But after watching teams drown in their own ‘expressive’ codebases, I’ve come to a different conclusion.
Adding types doesn’t give you more ways to say something. It gives you fewer ways to be wrong.
Think about it. When you add a type system to JavaScript—moving to TypeScript—you’re not unlocking new syntax. You’re closing off possibilities. You can no longer pass a string where a number is expected. You can’t call a method on null. The language becomes less expressive. But your code becomes more reliable.
This is the paradox at the heart of software engineering: True engineering power comes from what a language prevents you from doing, not what it allows. ‘Expressiveness’ is often a developer trap that leads to unmaintainable chaos.
You’ve probably experienced the relief of a compiler catching a type mismatch before deployment. That relief isn’t from having more options—it’s from having fewer surprises. The type system acts as a contract, a set of rails that keeps your program predictable. And predictability is the foundation of software that scales.
I’ve seen teams in Python add MyPy annotations and groan about the boilerplate. But six months later, they’re the same teams who can refactor confidently. The friction of writing types is a one-time cost; the chaos of debugging runtime errors is a recurring tax. Every line of type annotation is an investment in future you not having to debug at 2 AM.
Now, I’m not saying every language needs a strict type system. Dynamic languages have their place: prototyping, scripting, exploratory work. But when you’re building a system that must survive for years, with multiple developers, the trade-off is clear. Expressiveness is a luxury you can’t afford.
This runs counter to the ‘move fast and break things’ culture. But that culture works only when you’re the only one touching the code. In a team, ‘move fast’ becomes ‘move slow and fix things repeatedly.’ Neutrality is death. Pick a side: either you value expressiveness and accept the chaos, or you value determinism and accept the constraints.
I’ll take the constraints. Because the best code isn’t the code that can do anything—it’s the code that can only do the right thing.
FAQ
Q: Doesn't a more expressive language let you solve problems more creatively?
A: Creativity in code is overrated for production systems. The goal is to reduce ambiguity, not maximize expression. Types sacrifice a bit of creativity for massive gains in predictability and team productivity.
Q: What about dynamic languages like Python or Ruby? Should I abandon them?
A: Not at all. They're great for prototyping and small projects. But as soon as your codebase grows beyond a single developer or a few thousand lines, adding type annotations (MyPy, Sorbet) becomes a smart investment. The friction is real, but the payoff is survival.
Q: Isn't this just a preference for static typing vs. dynamic typing?
A: It's deeper than preference. It's a choice between two philosophies: freedom with risk vs. constraint with safety. The industry is moving toward constraint because the cost of runtime errors in large systems is too high. The 'preference' argument ignores the empirical reality of software maintenance.