Speed vs productivity is the wrong argument to be having about languages.

I recently read an article on python - Yes, Python is Slow, and I Don’t Care.

By the sub header I felt a little trolled; “a rant on sacrificing performance for productivity”, the presumption being that scripted soup languages like Python are more (trigger warning:) productive. This may be true with syntactical-nightmare straw-men like C++, but the arguments that held in the days that let languages like Ruby take hold no longer apply, and will hold even less in the future.

Yes, compiled, static languages are faster to execute (sometimes 30–60 orders of magnitude faster than python, which is unfair to dismiss outwardly as ‘not a tangible benefit’), but this is absolutely just a happy by-product. However, if you actually believe this is the only reason you’d choose a statically typed, compiled language, you are who I wrote this article for.

Note that in this article I’m going to use examples from languages that are statically typed and compiled as a counter-example to python (and other languages of its class) being dynamically typed and interpreted. I do not talk about other aspects of the language class such as object oriented vs functional, as these don’t have as big an affect on the ‘speed’ debate, though these could be interchanged with the same basic argument in some of the points I’ve tried to make.

Instead of speed vs productivity, lets instead think about things in terms of safe vs convenient.

Speed and productivity are not good metrics because they often change throughout the lifetime of a project. A language might be fast and productive to begin with, but slows down as the codebase expands.

Safe

Long term productivity, and maturing as a developer, is a result of safety, knowing you as a human are fallible, you make mistakes, you’re forgetful, your code and your thinking actually sucks, no matter who you are. So you rely on the computer a bit more in areas it is good at.

Your compiler and language can help you be more articulate, direct, and correct. You want to eliminate places bugs can hide. You want your compiler to tell you immediately where a bug occurs, so you need to feed it enough information to reason about your mistake. Also you want to be able to understand your code later without having to debug it manually or poke around with reflection.

I think there’s a sequence of steps that occur when a programmer spoiled with being lazy on dynamic types encounters when they start a static language. They wrestle for a few hours at some point trying to mash types together and it feels like a “round peg, square hole” type of situation. It’s easy to blame the language here but instead, it’s your compiler / language telling you something (or in some cases you are learning a weirdness of the language or how computers like to work). Maybe what you’re doing isn’t the right approach and you should simplify…? But it’s easier to throw it against the wall as the language being unproductive, right? Certainly it was easier when we could quickly type out some ambiguous code in ruby and it just worked. Till it bites you later because it is poorly designed or overly complex.

Convenient

Convenience, on the other hand, gives you a short speed bump (slash endorphin rush) at the start of the project then slows you down progressively when your project grows to production size.

The current popular frameworks and languages market themselves to the impatient generation. Shove up a quick code-preview on how easy and slick it looks to chuck the most common use cases together, hell you could almost copy paste that snippet and be done. This is the endless cycle of the perpetual small-project engineer. When they finally get to a large size, there’s something new to grab onto that has all the panaceas of a short term code snippet.

Here’s another thing, this short term productivity boost only really occurs when you are unfamiliar with the language in question. More articulate languages have a learning curve, it’s true — but why are people so afraid of actually learning something that makes you more efficient, productive, and decreases the amount of stress in your life?

In conclusion…

I’m not giving examples of perfection here, because there aren’t any. All languages currently have their own drawbacks, and it’s up to you to evaluate what is right and wrong. I’d say a current drawback of many compiled / static / functional languages is lack of community support and library availability. But maybe that’s because of articles that post misinformation, and we need to support the idea of clarity and correctness more.

Python (insert javascript ruby whatever) is not bad because it’s slow. It’s bad because it’s not safe. It’s bad because it happily lets you create beautiful, syntactically correct, neatly formatted bugs. It’s bad because it pushes the responsibility for correctness onto elaborate testing frameworks that are fallible and gap-prone. It’s bad because it’s not long term productive. It’s bad because it strives for being convenient over being safe.

The days of crazy pointer and manual memory management hell in modern languages are over. We just need to give modern languages a shot, invest in our own education and improvement, and not be so lazy and expect our code to be so “cut and paste in a single line”.

Good design is hard, but safer languages that are themselves well designed, will help you get there. But they need a community, richer libraries, and support.