The Language Doesn't Matter
This is in reference to [[Programming Growth Implementation vs. Theory]].
I used to think it was important to get exposed to different programming languages and ways of coding. I don't really think this way anymore.
The best way to improve as a programmer is just to implement stuff: write code, explain code, test code, in whatever language you want.
I think this mindset is well-represented in the following places:
- Shopify's performance engineering: [[To Thread or Not to Thread An In-Depth Look at Ruby's Execution Models]]
- Sorted containers: [[Python Sorted Containers — Sorted Containers 2.4.0 documentation]]
- [[PyCon 2016 – Grant Jenks - Python Sorted Collections - PyCon 2016]]
Basically, both reject the premise that languages like Python and Ruby are slow. Yes, they potentially more memory-hungry and slower in some use cases. But there's no reason from first-principles that they have to be slow. It's just CPU instructions at the end of the day, isn't it?
And so from the same perspective, learning many different languages doesn't guarantee that you become a better programmer. You can learn to churn out slop in many different languages, without fundamentally understanding the different tradeoffs, why one is better at a certain task than others.
For example, just saying "C++ is faster than Python" isn't necessarily true. You can to actually talk about what it is faster at. It uses less memory? Yes, that's generally true because you have to mostly manage your own memory in C++.
But sortedcontainers is a great example of the opposite. They used their fundamental understanding of how python works, how the CPU / memory / CPU caching works to write some very fast data structures in all native python.
In the talk, Grant says "don't program your language, program your interpreter". Meaning, develop an understanding of Python as DSL on top of assembly to take advantage of the raw power running underneath it all. You can only get here by writing lots of different pieces of software with different requirements all while understand their limitations/strengths.