close up photo of person typing on laptop

Thoughts on Static Typing

I don’t think I am the only person out there that has noticed a trend in the software engineering community away from dynamically typed languages like Ruby to statically typed languages like TypeScript, Java, and Kotlin. What I don’t entirely understand is why. While statically typed languages do provide some nice tooling and work well with IDEs and VS Code, I don’t think that’s the real reason that people are adopting them.

I think the current love for Java, TypeScript, etc., is based on a myth and misunderstanding. It’s based on the idea that if the code compiles then “it will just work” The idea that if there are no compile time errors, then the engineer must have gotten it right.

We are at a point where we have Rails and JS applications that are in the hundreds of thousands of lines of code. And the engineers on those projects are having problems. And they think that the solution is to start using, or to introduce, static typing. Just look as Shopify.

But will static types solve magically make the code base more understandable and easier to reason about? I don’t think so. Contrary to current belief, it is just as easy to create spaghetti code in Java as it is in Ruby. I personally think the problem is not the type system but the engineers and the code they have created.

Most code bases I have worked on where engineers are asking for static typing either have no tests or very few tests and the engineers do not use TDD and do not refactor. They have spent years creating terrible code and they are suffering the consequences of that. However, instead of cleaning up their code and adding tests, they want a silver bullet and they look at introducing static types. They think the extra tooling you get and the compile time errors will solve their really bad engineering habits and allow them to, once again, extend the code at speed.

For me, this just doesn’t make sense. It’s similar to wrapping a failing building in scaffolding to help hold it up instead of repairing or replacing the building. It will work for a while, but the building will eventually fall down.

If you want a code based that you can extend and maintain in a few years your team needs to be doing TDD with constant refactoring. You need to be following Robert Martin’s Boy Scout rule and clean up the code that you are working in and leave it cleaner than when you arrived. And this includes adding tests. This is the only way to ensure you have code that you can reason about, understand, and continue to work on.





Leave a Reply

Your email address will not be published. Required fields are marked *

Copyrighted Image