Recently, I shared a long Twitter Thread while I went through a bunch of GitHub repositories that I officially archived — they are still all available of course, but I’m not caring to take issues, or pull request; if you happen to bump into something you would care to use, feel free to fork and use it.
As these projects come from many different “eras” of my career, they all are different in style, license, and programming language used. I already have written before about my current take in licensing, so I don’t think there’s any need for me to go through more of it right now. But I didn’t really spend much time talking about languages on the blog, so I thought I would at least share my point of view with this.
I started programming with BASIC, on C64, GW-BASIC, QBasic, and eventually Visual Basic 5 CCE. I went on to learn C++ for high school, I tried (and failed) learning Pascal. I learnt PHP because that was what seemed cool, and I couldn’t get into Java at first at all. I learnt to appreciate “good old C”, and Shell. I failed at my first two attempts to get into Python, ended up picking up Ruby, and eventually C#. For a job I ended up digging deep into ActionScript (Flash’s programming language), and some proprietary language that was attached to the RDBMS that they had been using. To make my life easier, I learnt Perl (in 2012!) to extend Munin. Then I arrived at the Bubble with no knowledge of Python and was thrown in possibly the most Python-heavy team in Dublin at the time.
I like Python, but I also liked most of the other languages I worked with. But I look at languages like tools, and sometimes one tool is better than another because of the features, sometimes because it’s the one you have the most muscle memory with, and sometimes because it’s the one that is already in front of you.
And because I have changed my “dayjob language” a few times in the past few years, the language that my FLOSS projects were written in tended to change in sync — because that would be the language I’d have the freshest memory in. As I said, I used a ton of Python in the Bubble, and that’s why you can see me releasing a ton of Python projects now. If I had to write something in Ruby, I would have to go back and figure out how much the language changed, and what the current best practices are — this is also true for all of my old projects: if I were to pick up ruby-elf again today, it would probably take me a few days even just to figure out how Ruby evolved since seven years ago (the last time I touched it). If the project didn’t have as much code and test and complexities built in, it would probably be faster to just rewrite the whole thing into a language I have more confidence in. Which probably shows why there’s so much stuff I abandoned over the years.
Of course there are developers who focus on one language and know all of its inside out. They are the ones that make languages possible. But that is not what I do, it’s not my dayjob, and I am much more likely to just accept what the status quo for a project is, and adapt. I can only think once of having rewritten something because of its language — and ironically, that was rewriting Python in Perl. Although in that case, I think the problem was less about the language (despite my ranting back then — little did I know that a few months later I would be forced to learn Python), and more about the language providing a flat battery.
I find that the same is true from a company/employer/project owner point of view — languages are tools. And that means sometimes you stick to the tools you have, and not “buy” more tools (in the form of hiring experts or spending on training), while sometimes you don’t care which tools are used in the shop as long as the results are valid. When you have to build some software that a team has to maintain, for instance, you may not want to introduce a new language just because it’s the preferred language of one of the programmers — even if the language is perfectly fine by itself, you need to consider the cost of relying on a single person being the “expert” in that language.
This does not mean that developing new languages is not useful or important. Or that the differences between languages don’t matter. I really enjoy writing Python — but if I needed to write something that is very high performance I wouldn’t go and use Python for it. I’m enjoying CircuitPython as it makes quick prototyping awesome, but I also understand it’s a limitation, as it needs more expensive components to run, and if every cent of your BOM counts, it might be a bad choice.
I also am holding hopes for Rust to become useful as a “base system language” to replace good old C in a bunch of places — if nothing else because removing entire classes of mistakes would be nice. But that is also a compromise: it might introduce new classes of mistakes, and it will have side effects on bootstrapping new architectures. I never expect any migration not to have any costs.