Programming Languages as Religion
The programming language wars are a distraction from what actually matters in programming, and in life - getting better.
Have you ever worked on a project where it was clear the user experience was being sacrificed to serve the developers? Where technology choices were made not based on performance requirements, but based on language X being the cool new thing?
People think the language choice matters more than it does. The choice only matters so far as you can finish the project and deliver a good user experience. Bonus points if you can skill-up, and though this is ultimately the most important thing, prioritising it can be unwise.
Your technical choices reveal more about your priorities than your skills.
What's discussed below:
How ego influences our technical decisions
The impact of our tool choices on users
Aligning technology choices with long-term growth
The Ego Check
Ask yourself: "If nobody would ever see my code or know what tools I used, would I still make the same choice?"
I do all my marketing on social media. It's probably how you found this newsletter.
I've had to learn what works and what doesn't. One thing that works is being divisive - picking a side, and importantly, picking an enemy.
"C++ sucks, use C instead"
"Rust is superior, only brainlets use C"
It's just like picking a sports team. People start to identify with their language/toolchain choice, and get defensive when it's criticised.
People get positive social signals by cheering on their favoured programming language in the right circles.
And then, when it comes time to make a decision about a project, they have chosen their team and are obligated to stick with it.
In reality, the best thing to do is remove ego from the equation, as difficult as that can be sometimes.
I look around and see people having arguments about languages. It reminds me of this tweet:
Tsoding is right on the money. I know because I was guilty of this exact thing - learning languages rather than fundamentals, thinking the language was the problem. In reality, every language I was looking at had the performance characteristics I needed - I didn’t need to change.
In 2018, I started writing a game engine in JavaScript because I thought the language was "beautiful". I fantasised about having some game engine in JS and all the JS people being impressed. I knew the performance was bad by default, but didn't really consider the implications.
I know game engines and games have been written in JS. The point is, the decision was ego-driven, not based in rationality.
I integrated pixiJS (a rendering engine), built an ECS entity system, and was getting horrible performance. I didn't, and couldn't understand why - because I didn't know programming.
My mindset today is very different. For example, recently when looking at building a digital signal processing application with a friend, I considered first the performance, second the user experience.
I decided on C++, as that's what he uses and it works fine. But, also there are important libraries: miniaudio, and imnodes. An audio processing library, and a graphical node plugin for dear imgui.two
If I let my ego make the decision... It would have been Odin, or C. It would have been no libraries, no standard library. I doubt it would have gone anywhere.
User Impact
That brings me to the next question: "Am I prioritising development convenience at the expense of my users' time and resources?"
Have you looked at your target market and what their median specs are? Do you know how many cores their computers have, at what speeds, and how much RAM they have?
if you are a PC game developer, have you looked at the latest Steam Hardware Survey?1
Since this is not social media, I can allow myself a bit of nuance and say that there are always trade-offs. You may not be able to do the best thing for performance (user experience) because it'll cost you too much time (project runway) and so you have to choose between having no product, or one that eats the battery of people's laptops.
You can patch it later... If it's up to you.
Here's an example from today. I tried the new note-taking software called Kortex, and it uses 1.4 GB of memory without me doing anything.
I'm not willing to use it right now, and that's a direct result of their choice to write bloated software. When the global average PC has 12 GB of RAM, and the OS takes up so much of that nowadays, I can't be the only potential customer that is pushed away by this.
The Decade Test
Finally, and most importantly, ask this: "Will mastering this approach teach me principles that will remain valuable for decades to come?"
My journey into systems programming languages started in 2019. The improvement in my skill as a programmer is astronomical. I put this down to being forced to learn fundamentals - especially about memory.
The difference is so stark that I wonder how I ever had a job in web development in the first place. The answer, I think, is that I was tech savvy and knew how to read documentation.
Rather than focusing entirely on frameworks, which are constantly changing, I found value in implementing things from scratch. Things I can tailor specifically to the project.
Now, when utilising libraries in my code, I can understand the building blocks and make better decisions, not just look at the API.
The biggest unlock for me came by learning a bit about memory allocation and how CPUs work. I can make reasonable decisions about how to approach certain problems with just a few simple techniques2.
Key Takeaways
Rather than choosing tools based on identity, instead ask yourself what's best for the project.
Every tool choice is a trade-off for you and your users - they are the ones you are building for, so don't forget them.
The most valuable long-term investment is principles/foundational skills. Invest in yourself to compound long term gains.
If you enjoy this newsletter and want to go deeper, with more structure, I made Program Video Games for you. Transform your game ideas into working systems from first principles.
