Dynamic typing in the long run
Avishkar Autar · Jun 24 2016 · Languages
There’s a lot written around static vs dynamic types. More and more, I’ve tended to favor static typing; I like compile-time checks and static analysis, I like the strong contracts established between caller and callee, I like the readability of knowing what a function expects and returns from looking at its signature, and I like the refactoring capabilities that IDEs can bring forward from being able to trace references at compile-time. Even with my bias, I’ve never worked on a codebase that’s lived for 10 years, and I found The Long-Term Problem With Dynamically Typed Languages to be an interesting perspective.
Unit testing to prove correctness:
…relying on a giant test suite and test infrastructure to prove the correctness of renaming a function or adding a parameter, in practice, is a significant coefficient of friction on the software’s ability to evolve over time.
Not improving core APIs results in a kind of broken windows effect. When APIs are confusing or vague, people tend not to notice other confusing or vague APIs, and it slows everyone down in the long term.
Thus, instead of easily refactoring the legacy APIs, people think “I’ll just make a new one and migrate the code over!” And now you have two hard-to-change APIs. And then three. And the cycle continues. Additionally, this cycle is fed by architect types who know or think they know a better way to do things, but can’t be bothered to update the old systems.
Cost of change:
…a type system flattens the cost of change curve. Small API or performance improvements that otherwise wouldn’t be worth it suddenly are, because the compiler can quickly tell you all the places that need to be updated.
Data flow and mental understanding
…the most important component of understanding software is grasping data flow. Programs exist to transform data, and understanding how that’s done is paramount. Types accelerate the process of building a mental understanding of the program, especially when lightweight types such as CustomerId (vs. Int) are used.
Cost of change is interesting, as the flexibility of dynamically-typed languages is usually viewed as beneficial and yielding shorter development times.