Three Types of Software
Imagine there are only three programming languages: C, Haskell, and Ruby.
There is a very small overlap between them. There’s not a lot of types of software that more than one of those languages is suitable for.
- an operating system? -> C.
- a bank? -> Haskell.
- your SaaS app? personal blog? -> Ruby.
- AAA games? -> The engine in C, the gameplay scripting in Ruby.
- Bun, the JavaScript runtime designed for speed? -> C.
Yes, the boundaries are fuzzy. It’s all a spectrum, I get it. But…
I’ve realized over the years, that it’s nice to ask yourself “What language would I choose for this thing I’m working on if only those three languages existed.” It helps with architectural decisions, prioritization etc.
You’re probably familiar with the “Good, Cheap and Fast” Venn diagram. My question about programming language choice in an imaginary reduced world isn’t just a polyglot flex. It `is, at least for me, more useful.
Firstly, we often say that you can only choose two from good, cheap, and fast (i.e. if it’s good and fast, it must be expensive), and here you can only pick one, optionally zoom in, split your thing into parts, and the process of it provides insight.
And secondly, it helps to be sincere with yourself. Half the people are gonna say they want their thing to be good. Who would admit they want to make something bad?
Obviously simplifying, let’s say that all Haskell programs are correct, with low number of bugs; all C programs are performant, because why else would you torture yourself; all Ruby programs are pleasant to write, help you achieve product market fit, and even if you pay your developers a soccer player salary, they don’t have to spend ages to build your thing, thus — cheap.
Thinking of fast as performant, snappy, like low-level code, close to the machine; instead of fast to make (often a synonym for cheap), allows us to split the good into performance and correctness, and think about trade-offs between those two.
But even if we redefine the adjectives in our Venn diagram, it still feels like intersections between them can be easily selected. Picking a language simplifies the problem.
It allows us to reduce a 3D space into a single choice, a guess, a simple question of preference.
In reality, with a finite focus to spend, balancing between 3 qualities is like picking a point on a sphere octant.
x2 + y2 + z2 = 1 where x, y, z ∈ [0,1]
Try clicking a point on the octant, then stop hovering, and find the same point again after the octant rotates a bit. Not easy, right?
In many job ads and company culture docs you’ll see a sentence like “prioritize speed and quick iteration with a focus on quality and excellence”. I don’t disagree that we should strive for balance, but I feel that people often discount how many different balances are there. Like all vectors on length 1 on the plot above, all of the |ℝ| balances are valid. Each for a different situation.
Locating where you are on the sphere octant is hard. Deciding where you wanna be, and how to move to that point is harder. Choosing one from three “paragon languages” to guide the decisions you make when you build your JavaScript or Python software is a neat and easy heuristic.
Thanks for your attention.
Do you want fast JavaScript? Write it as you write C.
Alternatively, instead of a language, pick one of two YouTubers.