Sunday, August 20, 2017

Types as Communication

In my last post about static typing, I missed something.

My current employer is larger than any previous employer I’ve worked with, at least on the tech team side, and I’m getting a lot more interaction with other programmers.

Mostly, they’re a pain… because I have a tendency to nano-optimize for fast. Following the ground rules, my PHP code is fairly likely to cheerfully Do The Wrong Thing™ if it’s passed some incorrect type. It might leave Important Data blank, or outright crash.  My general attitude was, “Don’t do that, then!”

But I can also see that it’s a drag on other people.  They write code, it looks reasonable, maybe it even runs, but it quietly gives an unexpected result.  I wrote some code that took an int to pack into something. When it received a string, it would silently pack 0 instead.  Fortunately, the developer realized they were making an assumption, and checked it before that bug made it toward testing or production.  A different developer may have rushed on ahead and released it.

This leads to an intriguing property of static typing: the types become an additional point of documentation between programmers.  And unlike doc comments, they never go out of date if the compiler insists on their correctness.

The stronger the type system, the richer that communication is.

Which means that the most interesting comparison is not along the lines of Python vs. Java, but Python vs Haskell.  How easy is it for a team to work on a Python codebase, compared to Haskell?  How easy is it when the code is 2, 5, or 10 years old?

No comments: