Eli Bendersky's website Around eight years ago, I wrote a post in this blog called My current programming language arsenal, in which I summarized my main toolbox of programming languages at the time, and what I tend to use those languages for. Recently I felt like giving it another go, since so much time has passed, and quite a lot has changed. So in this post I will discuss the current languages I tend to use, as well as review the fate of the languages discussed in that old post.
But a bit of background first. Back in 2006 I wasn't doing a whole lot of programming in my day job. Those were my hardware/embedded engineering days, and writing software was perhaps 20-30% of my role. I was hacking quite a bit on pet projects, though. Since 2010 or so I switched back to a much more software oriented position and these days my day job involves more coding; on the other hand, I now have less time for personal projects.
Eight years is a long time, and my views in general have shifted somewhat; I now feel much less strongly about programming languages (and other "religious" issues in general). I value pragmatism more than shiny new features, and I believe that factors outside the language itself, such as availability of high-quality third-party libraries and a vibrant community matter a lot. I also prefer languages and idioms that make code easier to read, rather than easier to write.
Anyway, let's get going. First I'll start with the list of languages I'm actually using these days. The list is quite short - the following languages cover 99% of the code I've written in the past few years.
C and C++
I still combine these two under a single heading - it just feels more natural to me. Since I no longer write firmware for embedded controllers, the amount of pure-C projects I've touched recently is close to zero. Most of the code I write at work is C++, and if I need low level and high performance for some part of a pet project, I pick C++ as well; some parts occasionally remain in C, such as APIs for easy embedding, bits and pieces of headers and ABIs, and all those things that come as a result of C being the official systems programming glue language. But the bulk of the code is C++.
There's actually just one pure-C project I've been involved with in the last few years, and that's the core of CPython. It's not your uncle's C, though; when you hack on CPython (or implement pure C extensions to Python) you actually write somewhat object-oriented code with manual reference counting.
My feelings about C++ are still mixed, but less so than in the past. As I said above, age and experience have brought a certain pragmatism with them :-) This really deserves a separate post, though.
Another thing I wanted to add is that, in general, I really like the additions that C++11 brought; moreover, C++ seems to be more actively developed than ever before, and future standards promise even larger positive changes. With the ascent of Clang, tooling has also greatly improved. Sure, some complexity is inevitable (perfect forwarding and universal references are not for the faint of heart). But all in all, C++11 is less burdensome and more pleasant to work with than older versions. Things like smart pointers finally being part of the language core a big deal, IMHO, because it forces programmers to standardize on a convention, rather than invent a plethora of ad-hoc solutions other programmers have to decipher.
Python
I listed C and C++ first because that's what pays the bills; but without a trace of doubt, Python is my favorite language, and the tool I'm most likely to reach for when doing something for fun. Python serves a lot of roles in my arsenal. It's a prototyping tool, a scripting language (my rule of thumb is to convert any Bash script that grows longer than 5-6 lines, or grows control flow, into Python), a server-side programming language, a language for numeric and scientific explorations, and much more.
I'm a Python core developer (though I admit I used to be more active in the past - I'm still planning that comeback), and consider myself a diehard Python afficionado in general. Whenever I want to implement something, Python is my first choice and I really try to stick to it unless there's a good reason not to.
That said, I don't think Python is perfect and is the right tool for every job. Obviously there's the performance issue. But also, recently I became intrigued by claims made by programmers I respect about the difficulty to write and maintain very large projects in Python, because of its flexibility and dynamism. I'm not expressing a strong opinion here for now, but it's definitely a topic I keep an eye for.
Javascript
A pragmatic, professional engineer will know when to keep his feelings out of rational decisions. This is very relevant for my "relationship" with Javascript. Do I like the language? No. Do I think it's a well-designed language? Lulz, no.
Do I think it's amazing that there is some language that's so universally standardized and supported for in-browser programming? Do I think it's amazing that any kid these days can pick up any computer with a browser and a text editor and write real programs, even complete games, without installing anything else? Do I think it's amazing that a web application can replace a GUI these days, leading to standardized interfaces based on open platforms, rather than proprietary GUI mega-frameworks? Yes, yes, yes!
I don't get to write much Javascript; close to none at work, a bit for personal projects here and there. But I do like the web. I do think web apps are superior to GUIs (even when just running locally). And I do realize that Javascript is the standardized language to do this, so that's what I use. I don't subscibe to the "compile-my-awesome-language-to-JS" bandwagon; these are fads that come and go. Attempting to dilute this space with a multitude of language kills one of its charms, IMHO. Javascript itself is a good-enough language to get the job done, and there's a stupendous amount of documentation, libraries and community activity around it online. If you have a problem in JS, someone, somewhere has already solved it and documented it.
The language has its warts, for sure; but there's some hope at the end of the tunnel. ECMA standardization seems intent on improving the language in the future, and with backing from companies like Google and Mozilla, we may see improvements sooner rather than later. It seems like JS is not bound by the chains of old Microsoft browsers anymore, which adds to its appeal. Who knows, Javascript may become a likable language one day.
What happened to Perl, Ruby and Lisp
It's curious that three of the four languages featured prominently in the initial post are no longer to be seen. Python is the main culprit here; let me explain.
When I wrote that post, it was at a point where I started getting disheartened with Perl, mainly because of its obfuscability. I started "flirting" with Ruby, and Lisp was constantly in the background as the "perfect, maybe some day" language. But Ruby turned out to be disappointing. The languange never seemed to really catch on outside the Rails community, and it showed. Once I saw Python and played with it a bit, Perl's and Ruby's fate was sealed very quickly. From Python I got the best of both worlds - a clean, powerful language on one hand, and a great community with support for all kinds of programming on the other. This turned out to be one of the best decisions I made, since Python exploded in popularity in the last few years and started capturing even more niches, such as scientific computing.
What about Lisp? This is somewhat more interesting. Lisp has always served the role of the "ideal language in the sky" for me - something I'm perpetually waiting for to become feasible for real-world programming. I was really enjoying myself with Lisp, but also not happy about the dearth of libraries and community. Well, Python made that go away too, because I also really enjoy writing Python.
There's really just one significant thing Lisp has and Python doesn't - macros. While I think macros are immensely cool, with time I also started questioning how features like macros affect programs in the long run. With experience and age came the realization that code readability, both for yourself and for other programmers, may be way more important than the most succinct way to write a program. I won't say I have a final opinion on this, just that I don't miss macros all that much when coding in Python.
None of this is to say I lost my affection for Lisp, of course, just that I see even less chance of using it in a real project in the future.
Looking into the future
So I've discussed the present and the past, but what about the future? What languages and technologies am I currently keeping my eye on and/or plan learning?
There's a couple. First, Go. I was long disappointed by not seeing any language designed for concurrent and parallel programming in the mainstream. Most popular languages have libraries for these things, but I'm talking about core in-language support here. I was thinking of starting to learn Erlang, but then luckily Go came along. I spent a few days tinkering with the language and I enjoy it so far. It has its warts, but overall I like its design. Especially the built-in concurrency primitives. Now I just have to find an interesting pet project to put it to good use...
Another is Rust. I haven't really looked into it in any amount of depth, but I'm definitely keeping an eye here. Rust is super ambitious because it challenges the king of the hill - C++. At this time it's still way too early to judge, and the language isn't even finished yet, but I'll be following with interest. Can a new language unsettle C++ from its throne of the system programming kingdom? Time will tell.