The Incredible Irony of Dynamically-Typed Languages

Ani Ravi,ProgrammingTypesLanguagesDynamic

I come with an extremely strong bias, which is that computers should juggle meaningless minutia, freeing people up to work on more interesting, domain driven problems that actually provide value to the world. In computer programming, the best tool that we have to juggle this meaningless minutia is something called a "type system", and a very expressive type system like the ones provided in languages such as Haskell allow you to model your domain in code. With the help from tools, languages, and research that's been around for decades, we can get pretty far with our computer-aided tools. However, the incredible irony is that programmers, whose only job it is to build computers and programs that help us, don't want to use the tools that we have available to us, that make our jobs as programmers sane. Especially when working on teams with multiple people with serious production codebases that are more than 10 lines of code doing real work such as moving money, or handling your medical records.

I find it astounding that entire programming languages and entire industries have been built on disregarding good ideas from the past, so programmers can ship bug after bug caused by "undefined is not a function" or "key foo not found in bar", or "I expected a Post here, but you gave me a User instead". Even worse is when the errors are non-trivial, and are deadly silent bugs that would've easily been caught by a type system. Our goal as programmers should be to turn as many domain errors into type errors as possible, so the computer can catch our mistakes and we can go on with our lives. Whenever we need to make important changes to our codebase, we should be able to be focused on solving the actual domain specific problem at hand, instead of having to search through the entire codebase to figure out what data structures, functions, or other pieces were affected because of a particular change that was made. We have tools to help us do this, but we code like we're in the stone age.

I'll be frank. I find this type (no pun intended) of programming insane. Coming back to the point I mentioned earlier, isn't it amazing that programmers build things to automate so much minutia away but we don't want to give away control for our own jobs, to a set of tools that could make our jobs so much more interesting than having to spend hours upon hours asking meaningless questions about your code that a tool should answer for you? When a computer can help us write code, we find every excuse to not learn how to use it (e.g. it "slows me down") and use subpar tools that rely on exerting double or triple the mental effort and time, just to get more buggy code. That mental effort isn't going toward expanding your mind, learning new ideas, or finding better ways solve problems in your code or in the real world, it's "where the heck am I using this argument inside this data structure I just changed" or "what is the value or shape of the data I'm passing in here", AKA meaningless questions that programmers, who get paid so much money, should not be spending half their time thinking about (if you think half is an exaggeration, it's not off by much when compared to the reality).

Don't get me wrong, I want to get paid as much as the next person. However, it's astounding that we are as efficient as we are, given how much time we waste on nonsense that doesn't have to do with actually solving problems and/or developing more knowledge. Then again, the world is so inefficient that even our inefficiency looks super productive in comparison. That's the only explanation I think of for how we've gotten this far and how we get paid so much given so much code out there is just jungle science and written with very little rigor or attention, using world-class tools that people should be using but don't.

There's light at the end of the tunnel though. Programmers are starting to realize that when they work in a team of more than one person, and their codebase becomes completely unmaintainable within a few years, that there must be a better way. And it turns out there is, not because people have new ideas on how to do things, but because ideas that existed for decades are finally being taken seriously by more than a small handful of passionate programmers. TypeScript is mainstream. Rust is seeing a lot of interest from big and small companies alike, and Rust's most unique feature (compile-time memory handling with no garbage collector at runtime) is possible because of research on type systems. Haskell is starting to see more serious interest not just from larger companies, but from startups that are taking off.

A lot of effort into the more niche statically-typed functional programming languages and tools (e.g. Haskell, OCaml) has come from volunteer efforts and a few notable companies, as the number of industrial programmers in these ecosystems is still quite small. As more young companies develop talented engineers that push forward serious, statically-typed languages to do real work that can manage the insane complexity behind large-scale software, there's hope yet that programming will eventually become sane, and the tools, much more sophisticated. That's a future I can get behind.

Ani Ravi