WordPress up and running
I have finally migrated my blog to WordPress! You do not need to change anything in your feed reader though; the feed URL has remained the same. Posts have prettier URLs now, but the old ones still work thanks to mod_rewrite. I have migrated all of the comments, including some that had been lost in the third and final crash of BlogEngine.NET (the one where it took down a dual-core, 4-gig box all by itself after the quad-core server post made front page on Reddit). Commenting is back to normal, and my overdue replies are coming. The only impact to readers, I hope, is that some RSS aggregators will show duplicates of previous posts marked as unread (luckily it’s only a few posts since the blog is new). Google Reader is smart enough not to do this though. I’m happy to resume writing and thrilled to be on a more stable platform. Thank you for your patience.
Programming Language Jobs and Trends
In the last entry I argued that while learning programming languages comes at a high cost, good programmers should be proficient in multiple languages. I think of programmers as having language sets, based on the idea that knowing one language is not enough for a professional. The task then is to pick the language set wisely to minimize learning time and maximize the benefits to your career. Like other programmers I enjoy toying with different languages, but I’m conservative about fully picking up a language because there’s too much process loss involved. I go for the minimal language set. This is a look at various languages from this point of view; I hope it’s useful to other programmers.
There are many criteria I find important in a programming language, from job market to whether it’s fun. This post looks at jobs, job trends, and overall trends for languages. First, here is data for number of jobs per language across the United States, measured roughly using Dice.com searches.
These are rough ballparks, but they do reflect the relative demand for each language. I couldn’t search cleanly for C and ML so they’re out. Haskell, OCaml, and Rebol had fewer than 10 jobs each. Recruiting for some of these languages (and for LISP) often happens in a more targeted way. Also, JavaScript is useful nearly everywhere nowadays, so the number of jobs understates its importance. Anyway, that’s them results. Without knowing the supply of programmers for each language, it’s hard to say anything about the relative difficulty of landing a job. But that is not the point; after all, most programmers who spend time on programming blogs get jobs easily (at least in the current markets).
An abundance of jobs is important because it gives you choices. You’re more likely to find a job or contract that better suits you. The more options you have for jobs, the more likely you’ll find the one with the telecommuting, the long vacation, the fired-up team, the interesting project or the right industry. Above all, you have a better shot at working with non-assholes. Martin Fowler says that early in his career he decided that he "wouldn’t work with unpleasant people, however capable they might be", since people matter most. Amen. There’s no better insurance against assholes than multiple job offers or clients.
Java, C++, and C# clearly take the market demand cake. Java is peculiar in that most jobs require some significant experience in some other technology, like IBM WebSphere or BEA WebLogic. So the market is fragmented. By contrast, the C# market is more monolithic: people use whatever Microsoft gives them. There are pros and cons for each one. The main downside for Java is that most programmers qualify for only a subset of jobs, whereas if you know C#/.NET most Microsoft shops are viable. The flip side is that as a Java developer you get to choose a lot of the technologies you use, while for C# you may have to use whatever ships out of the box (sophisticated teams excepted). Java programmers can find sweet contract rates if they know the right stuff. The data at RealRates.com seems to support this (though it looks like they stopped updating the site). C# programmers are more of a commodity. This drives down rates but contributes to platform adoption. For what it’s worth, here’s job growth measured by Indeed:
The C# growth surprised me. If the data is accurate, that’s some striking growth for an established language. In script land, Indeed’s data shows Ruby growing at break-neck rates:
Update: these Indeed charts show growth, not absolute numbers. They are relative: C# and Ruby are growing faster, but in absolute numbers they’re below their counterparts. If you click on these charts, you’ll be taken to the Indeed web site where you can plot absolute numbers if you’re so inclined.
Salary data is less relevant. You can’t reason much based on the free online reports (from Indeed, Salary.com, etc.) because the data is dodgy and not broken down by relevant factors. Frankly, language is not the determining factor of salary and contract rates, so there’s no point sweating it. Some specific technologies might command a premium, but it’s hard to generalize to a language. Dr. Al Lee from Payscale.com has a post discussing programming salary comparisons. His discussion is insightful but I would not base any decisions on income statistics. Too much of it is up to you, your negotiation skills, employment setup (employee, brokered contract, direct contract), experience, local market, etc. If you really want some numbers, I’ve set up an Indeed Salary Search for the major languages.
Job market trends don’t fully capture the feeble whims of us programming folk. There are other interesting ways to look at mind share and what might be coming down the pike. O’Reilly published trends based on book sales here, but that’s about a year and a half old. Google Trends yields interesting information, complementary to the Job Trends feature at Indeed. Based on Google Trends you can see apparent decline in PHP, the rise of Ruby over Perl and Python, and plunges in C++ and J2EE. Financial results for Q4 2007 show strong server revenue growth for both Linux (11.6% year-over-year) and Microsoft (6.9% year-over-year). Microsoft’s Q1 2008 was impressive. Here are some of the Google Trends:
I’d take trend analysis with a grain of salt; yet the direction of movement looks consistent across different sources of data. It’s also consistent with the idea one gets from reading blogs and talking to colleagues. Namely, the rise of Ruby among the scripting languages, a relative decline of Java and PHP, and C# moving steadily. I’d take these trends into account when deciding on a language to learn. But a quick look at the job numbers for COBOL should put things in context. There’s no urgency and it’s only one factor.
So much for the market. Picking a language based on market statistics alone would be like choosing your profession based on the projections in the Occupational Outlook Handbook. So next time I’ll write about the languages themselves and where I think they fit within the current programming landscape. That way I get sleep and this post stays manageable.
Language Dabbling Considered Wasteful
[Update: I have renamed this post. The original name, "New Languages Considered Harmful", was supposed to be a tongue-in-cheek way to get people thinking. I chose it playing off of the reference to Dijkstra later in the post. It's absurd when taken literally: every language was once "new", and what exactly should we stick with? ALGOL? Fortran? Analytical engine punch cards? Unfortunately it came across as incendiary, which was not my intention. This post is not about computer science education: I believe it's important for programmers to be exposed to a variety of languages and paradigms as part of their education. It is about how much professionals get from learning new languages. There are enormous productivity gains one gets from sticking with a small set of orthogonal languages; moreover, dabbling in languages is overrated as a way to get better at programming (in particular, when compared to reading high-quality source code). Plus there's a world of stuff to learn, some of which I think has better returns than a new language for most programmers. Examples of these "language sets" could be C/Ruby/LISP, C#/F#/JavaScript, C++/Python/Java, etc. The sets are not static, but in my experience there's seldom good reason for change. In my own personal set I've had two changes in the last 7 years: Ruby displaced Perl and JavaScript got added. The original article is below in all of its flame-inducing glory.]
Learning new programming languages is often a waste of time for professional programmers. It may be a fun waste of time (i.e., a hobby), but it’s a waste nonetheless. If you do it for pleasure, then great, but profit is scarce. Pointing this out among good programmers is heresy: even the pragmatic programmers, whose teachings are by and large excellent, suggest we should learn one new programming language every year. That’s rubbish.
The theory is that by learning a new language you "expand your mind" and become "a better programmer". Right. By that kind of argument we should all be eating LSD (don’t). In reality learning a new language is a gritty business in which most of the effort is spent on low-value tasks with poor return on time invested. You need to get to know the libraries, struggle with the environment, find or tune a text editor, look for tools, and so on. Most of the effort has to do with housekeeping chores, which are surely not mind-expanding by anyone’s measure. If you hope to be productive in the new language, things are even bleaker: proficiency has less to do with the language itself than with the myriad technologies you must master to use it effectively.
Even core language learning offers dubious return. How much does it really help to learn a new syntax? How does it expand your mind to learn new operator precedence quirks? Much of what constitutes a language is lexical and syntactical bureaucracy. Worse, you’re learning absolutely nothing about fundamental aspects of computer science. No algorithms, no operating systems, no compiler theory, no math, no AI. If you’re an undergrad, then you should have time to pick up languages on the side while learning all that, of course. But a professional is making a trade-off: what else could you learn with that time? We’re better off studying business, security, usability, architecture, software estimation, and so on, rather than spending time with a different language every year.
If your goal is better programming, you will learn far more from reading high-quality code bases in your current languages than from a new language. Go read top-notch code in the languages you know already; it’ll teach you techniques and style quickly, plus different ways of thinking about problems, with the added bonus that you can actually use what you learn. You can also understand a lot about programming languages in general (issues like typing, scoping, functional vs. imperative) by reading a good book.
There’s another pernicious effect to language hopping: it hurts your momentum. Every time you rely on your current languages you get a little better. Not in a fluffy expand-your-mind way, but in a concrete way. You learn more about your libraries, you set up a new macro in the editor, you have a chance to use that new language feature. Scott Hanselman argues that learning a new language is sharpening your saw, but I see it as neglecting your half-sharpened saw while playing with the dull, new, shiny one. The upfront cost is not the only one either. It’s better to have 3 razor-sharp saws than 8 so-so ones. Each new language you add to your toolbox is making it harder for you to become furiously productive in any given language.
Forget Ruby - Here’s Clipper!
Yet, any programmer worth their weight in silicon must know multiple languages. Sometimes the new saw is of a different type altogether, and it’s worth having. Right off the bat there are major obvious reasons. Different systems or parts of a system call for different languages; that’s been true in any environment I’ve ever worked in. For a while this was mostly due to speed and level of control. My first apps were written for MS-DOS in Clipper, which was a database-oriented rapid development language. Fast to develop, but no power. Soon enough we wanted to add features that called for C and assembly. Using C we could write terminate and stay resident (TSR) programs and spice up our apps with features no one else had. Sometimes the issue was not so much power, but speed. There have been many happy marriages to deal with this: Tcl and C, VB and C++, Perl and C, you name it. Fast processors and web apps have largely killed the speed/power motive. Computers can happily run applications written wholly in Python or Ruby. And if they can’t, a different language probably won’t help; you just need more web servers. But alas, you now need to know SQL and JavaScript too, so we’re back to obvious reasons for multiple languages.
Aside from the immediate reasons, there’s some merit to the mind expansion argument. I think being proficient in at least two languages is indeed important for boosting your ability as a developer. This resembles human language: learning a second one changes the way you think and your perception of the world. The third or fourth, not as much. But it can’t be any two languages. If you know Portuguese and Spanish, your mind didn’t have to expand much. Likewise, learning VB.net and C# doesn’t count. Also, I agree that some programming languages are hazardous to your skills if used exclusively. Edsger Dijkstra claimed COBOL crippled the mind and that its teaching should be regarded as criminal offense. We all know who’s the new COBOL. Java, the kingdom of nouns, is a programming straight jacket. I imagine Dijkstra would have called for harsh no-parole sentences for any CS Department chairs whose students learn only Java. If you write a lot of Java code, being fluent in a richer language does sharpen your saw. This is true for other statically typed languages, but to varying degrees. More on that in a bit.
Java protects developer from self
You might think this is contradictory. You’d be right. Life’s not simple; sorry, I wish it were. The realities are:
- Learning new languages is very expensive (in time), a huge opportunity cost
- There is loss associated with using multiple languages: the "jack of all trades, master of none" problem
- A good programmer uses multiple languages
But there’s a sane way to deal with these. Why, you just need to find the minimal language set. The smallest set of languages it takes to crank out great software quickly while growing as a programmer and making rivers of cash. In the next entry I’ll talk about my personal language set and the factors I used to compose it.