Languages Matter

Giles Bowkett is a pretty smart guy, but in his recent post, "Languages Only Do So Much," things run off the rails a bit (no pun intended, for you Ruby fans).

I'm going to pass over his trainwreck of a religious metaphor pretty quickly, except to point out that it's awfully improbable to count the argument that virtually all cultures have a belief system that obeys highly similar principles as a warrant for believing in atheism, a belief system that stands in stark contrast to all of them. Surely it would be more plausible to count it as justification for some sort of religious unificationism. But like I said, let's set that one aside.

The real problem with this post is the notion that if you develop a personal style, you should write more or less the same code in any language. Should good programmers really write more or less the same code in Haskell, Smalltalk, and C? That seems awfully silly to me. They're good at vastly different things, so if you're going to write the same code in all of these, you might as well pick whichever language supports your idiom the best, and run with it.

I'd like to offer a counterproposal: learning and choosing languages is part of developing a personal style. Now, if you're picking between Python and Ruby -- or Java and C# -- the languages may be close enough that you can develop a style that works for either one and switch freely based on the requirements of a particular project. But some languages are very intentionally different.

There's no particular reason to write a web server using the same idiom you use for shell scripting. In fact, I think it's pretty silly to stick with exactly the same idiom in both places, because you're doing very different things. Depending on what your languages of choice are, it's perfectly natural to choose different languages and idioms for these different tasks.

Some of the different things you might need to do in a programming career include systems programing, shell scripting, web servers, web clients (i.e. JavaScript), desktop clients, application servers, scripting for extensible applications, problems that decompose most cleanly using objects, problems that decompose most cleanly using functional programming, and perhaps problems that decompose most cleanly using procedural programming. Certainly not every programmer will need to do all of these things, but most people will need to do a number of them.

It's unlikely that a single language (and likewise, a single idiom) will be an ideal tool for every problem area you face. In fact, I'll go further: trying to use a single language for everything is almost always a terrible idea. Perl started life as a brilliant scripting language, but now it's limping along as a somewhat broken general-purpose programming language. Java tried to be the One True Programming Language, and developed a framework so large that no one who wants to retain their sanity will try to learn all of it, and there is now vast interest in new JVM languages -- Jython, Groovy, Scala, JRuby -- that will cleanly interoperate with all the legacy Java code but are less painful to use.

So here's what I think: by all means, develop your own personal style. All good programmers will do this. But part of your style should be choosing the best tool for the job. If you write shell scripts, figure out what language and idiom are most effective for what you like to write, and run with it. If you write web applications, use whatever suits your style there, as well. Depending on what languages you choose, these may or may not be the same language. If you like Python or Ruby you may like them for both, whereas if C# is your language of choice for web applications, you will probably pick a different language for shell scripting. Powershell, perhaps. Even if you do use, say, Ruby for both, it is likely that you will use a somewhat different style for shell scripting than you use for Rails applications.

If OCaml is your language of choice, you may well choose it for both object-oriented design and designing functional code. If you prefer Haskell, then either you will need to pick a different language for OO, or simply choose not to use the OO idiom at all. If you write Java, you may want to mix Scala into your code to alow you to use functional programming. Likewise, F# offers similar opportunities for .Net. Some of the other languages for JVM and CLR offer additional choices for occasions where dynamic typing may be more efficient than static typing.

My point overall is that for many -- perhaps most -- programmers, a suite of languages that fit together well for you may be a more effective choice than a single language. And even if you find that a single language works for you, it will pay to learn a variety of appropriate idioms for different tasks. Languages matter, and imposing any one idiom on a variety of them is rarely the ideal.