Interpreted Languages Encourage Velocity and a Whole Host of Good Things
Tags: programming
November 10th, 2022

Come the 21st century, interpreted programming languages have come to rule the roost. The benefits are immense and obvious: more descriptive errors are available, it's faster to write-test-deploy, it's often more forgiving.

Coincident with that was the rise of Test Driven Development (TDD). More broadly, writing tests for code was rare prior to the early 2000s. Things like JUnit (1997) made writing tests easier and more grokkable. And out of that came the idea of mass refactoring as part of the development process.

The two are inextricably linked in my mind. Interpreted languages remove the friction of compiling and encourage more experimentation, more testing, and more confidence.

To start, the experimentation. This includes opening up an interpreter and checking the syntax you're a little fuzzy on. But it also means feeling more free to refactor parts of your code base. Test suites mock, monkeypatch, and set up fixtures. These are time consuming to scaffold in a "mini app" if you need to spot check/try something. You can add these right in the real code base and experiment there instead. But if your language is compiled, you'll languish through the build time and won't want to do it.

Testing begets testing. That means momentum is either on your side or working against you. In even the loosest interpretation of TDD, you write a test, check that it fails, write the fix, run the test suite, and see that it passes. If you insert a ten minute wait inbetween every step, you're compiling a language. That will encourage a whole lot less testing as a result.

If you're able to check things more quickly, you're more likely to want to refactor. Trying to refactor compiled code is like looking down the barrel of a gun: you know its gonna be awful to even try. And once you back in, it's often hard to back out. Over time, you develop an "eh, good enough" attitude which contributes to a less confident, sloppy codebase.

Using interpreted languages falls under the "more velocity = more productivity" paradigm. It's not just being able to move faster, but a lot of other effects that fall out of it. So if performance is not strictly paramount, for the love of god use something that doesn't have a build time!