Environmental Picks

I find it hilarious to watch programming language partisans astroturfing. Sometimes I even play along.

But as far as I’m concerned, things are pretty clear cut: You pick the right tool for the job, and even if you have favorites, you learn their weak spots as well as their strong suits.

By and large, and given that the most important factor in program design tends to be the way your data is structured and not the language you’re manipulating it in (a fact that pretty much everyone tends to forget at one time or another), I tend to pick a language based on the environment I’m working in.

In my experience, there are usually three types of environments:

• Environments you control
• Environments you have to put up with
• Environments you need to keep abreast of (or are exploring)

For me, what to pick in the first kind of environment is pretty clear cut: I can choose what to use, so I’ll use what I’m most productive in given problem constraints (which, these days, is mostly about performance and networking).

I do most of my stuff in Python because it saves me a lot of time when tackling weird inputs, alien web services and accessing all kinds of data stores, drop down to Go when I need more speed (or, in case of resource-constrained environments like ARM boxes, when I can’t be bothered to do C/C++), and use Clojure whenever I can for the sheer power of it¹ and as a neater, cleaner way to use Java libraries.

Go is a fairly new addition to my arsenal, and I kept tabs on it for a year before finding it “good enough” – mostly as far as the ecosystem was concerned.

And in between those three ecosystems, I’m guaranteed to find whatever third-party stuff I need to stop me from reinveinting the wheel – all of them are, if not mature, then at least guided by mature reasoning and tend to have pretty straightforward “best choices” for common tasks – even though the Go stuff is still a bit thin on the ground when compared to the variety in Python and the utterly amazing Java/Clojure universe, it’s shaping up quite nicely for its intended purpose (that is, high performance systems programming).

The second kind of environments is trickier – for me, it falls somewhere between mobile (like, say, when developing for Android or iOS) and web development (where you’re mostly stuck with JavaScript and might even have to deal with (gasp) – PHP).

You’re either constrained by the runtimes available or the tools you have to use, and it thus makes little sense to, say, target Android in anything else but Java – you can use a number of other languages, but you’ll usually be talking to core APIs, and if you’re pressed for time (and have nothing fundamentally against Java other than its ceremony) you’re much better off biting the bullet and diving in.

And the same goes for web development (now there’s one environment that is utterly out of control and that everyone has to put up with…). And JavaScript, the idiot savant of scripting languages, doesn’t make it easy. I’d love to have more options, but at least the tooling has evolved by leaps and bounds (if only because there are a lot of other languages targeting JavaScript) and it’s no longer half the pain it used to be.

The third kind of environment is the hardest to define – for me, it’s both a matter of keeping my skills sharp (Mono and C#), keeping tabs on things like Scala (which I’m not particularly keen on but can’t ignore), or dipping into OCaml/F# (which I’m quite keen on but have yet to dive into).

But the main point is that all of this is temporary (one might even say ephemeral). It wasn’t like this five years ago (not even one year ago, really), and I have no idea what it will be like six months from now (or even if I’ll still bother with programming languages). It’s your mind that counts, and what you do with it.

Well, as long as it isn’t yet another NodeJS concurrency hack². I think we’ve had quite enough of those, don’t you?