When it comes to programming languages, avoid the long tail
A brief diatribe on “long tails” in programming languages.
I was thinking about programming languages the other day, specifically about choosing one particular language over another. And, whether I care which language any of our companies plan to use for a given project. The bottom line is I don’t really care as different situations likely warrant different choices. But I am cautious about two things. First, I am careful about steering clear of languages that are getting a little too long in the tooth. Second, I don’t want to be too far out in front of the language. The only thing worse than coding in a formerly-was-popular-language is maintaining code that was written in a never-was-popular-language.
Let’s talk about old code first.
Take COBOL for example. Yes, there have been tons of great upgrades and advances in the COBOL language in recent years. (Thank YOU, Grace Hopper). But it’s an OLD language, born in 1959. And sure, the folks at Micro Focus offer a pretty advanced, visual version of COBOL with tons of bells and whistles. Heck, I would hazard to guess that you could probably build some fairly interesting things with their COBOL platform (maybe even RESTful interfaces for your web applications). To be fair I actually don’t know, but I am assuming they have kept the language pretty current. So why I would not want our companies developing in COBOL? I think it’s pretty hard to get your hands on good COBOL developers. I don’t see lot of kids coming out of college wanting to learn COBOL. Nobody is banging a drum to say that COBOL is something that they want to learn. So whether COBOL is effective or not effective for building a particular application does not really matter at this point. I would argue that writing a COBOL program and the logic layer for some RESTful web services interface would probably work just fine. It’s a fairly powerful language but the problem is finding people that know how to do it and want to do it. Clearly this is an extreme example. You are unlikely to choose COBOL as a language unless your company has a huge ongoing inventory of COBOL programs to manage already.
For my part, I have written a lot of CFML (Cold Fusion) over the years. Not good code mind you, but code nonetheless. My friend and compatriot Alan Willamson cringes when he hears me say “programming in Cold Fusion”, because I write a lot of crap. Mostly throw away stuff, proof of concept stuff, the kind of code that shouldn’t be checked into SVN. There continues to be ongoing investment in the CFML language, and not just from Adobe, but from a number of open source teams. In fact, Alan and the rest of the BlueDragon guys have done a great job of providing an open source platform for CFML. It’s fast, it’s free, and there is a ton of functionality built into the platform. Still, I don’t see too many newbie developers hankering to learn CFML. For me, it’s a go-to language for getting something done quickly. BlueDragon is written in Java, and I can write Java code directly in a script block in CFML. So it’s definitely the language I tend drop into when I have to do something incredibly quick. (Ok, ok, I sometimes us Transact-SQL for similar, albeit uglier, purposes if there is data involved).
Powerbuilder, it’s like your dad’s rock music, only much, much worse
Most people aren’t going to want to program in CFML anymore and it has nothing to do with the capabilities of the language. In the right developer’s hands, you can use CFML for a data access layer and restful web service business logic layer and you can do some dynamite things with it. It’s got enough object oriented capabilties to allow you to write code in a modern way. (We can get into a whole other academic argument about this last point, but let’s not and just say that we did). So while CFML is still a powerful language, I’d really worry about how easy it is going to be to find developers that want to write CFML. (And yet, we have a number of large scale CFML projects in our portfolio). There are a whole bunch of dead languages that once had a massive following that I’d throw into this same category. (CFML isn’t there yet, but it is probably headed there). Anybody remember PowerBuilder? It was clearly the dominant programming language of the go-go client/server days, maybe not as dominant as COBOL once was in the 70s and 80s, but close. You can still buyPowerBuilder, it’s even got enhancements to handle server-side development. The thing is, who wants to program in PowerBuilder anymore? When I am in a meeting with 25 year olds, most of them haven’t ever even heard of PowerBuilder. Much like kids don’t want to listen to their parent’s music, most developers don’t wany to program in their parent’s programming language. Younger developers want something new. Whether it’s better or not it doesn’t matter. You can make favorable arguments in favor of a bunch of different “old” languages as far as feature/function is considered. But as Bill Murray once yelled out in “Meatballs“, It Just Doesn’t Matter. New developers are going to choose C# over VB.Net (even though both languages get access to the same set of features via Microsoft’s CLR). That battle is over. To be fair, Visual Basic and the grandaddy of them all, “C”, stil rank fairly high in Tiobe’s programming language popularity chart. In the case of “C”, I’d argue that system software still tends to be written in “C”, so it will always have a following. In VB’s case, I’d argue that it’s the long tail of legacy applications. Since software applications can have a fairly long life, programming languages tend to have a very long tail. Nobody’s really writing new stuff in them anymore, but there is still a ton of old software that needs to be maintained.
New kids on the block
On the other end of the scale are new languages that might or might not catch on, such as Google Dart. (Again, dear reader, I am not arguing either for or against Dart, just making the point that it is a relatively new language/platform and therefore does not have a large following of well-trained developers as compared to Java or PHP or Ruby as of this writing). New developers don’t really want to program in old languages, and I don’t really want new developers building applications on a language that might not live very long. There is nothing worse than having to maintain lousy code written in a language that never really caught on. Dart could end up being the next PowerBuilder, or the next Ruby. (But it might be the next Ada). The problem with new languages for mid-market companies is cost. The laws of supply and demand dictate that when you have a short supply of something (i.e programmers that know DART) then it’s going to be really expensive to pay those people. And you’re going to get outbid by the larger corporations and the venture-backed companies in Boston, Austin and San Francisco for DART talent.
The other problem with the leading edge is that you still have lots bugs (or missing features) in these products. You are still “debugging” the language to some degree. They can’t do certain things (like maybe connect to your favorite database). So you end up waiting around for the “complete solution” as Geoffrey Moore would put it. Furthermore, most new languages lack a set of well-understood “best practices” early on in their lifecycle. The code that you write might end up needing to be rewritten to achieve scalability or reliability. The bottom line is that I don’t want to skew too far back or too far forward when it comes to programming languages. You don’t get the benefits out of being out on the edges — at least in the middle market. Beyond that, I don’t really care.
In the end, you have to make a choice
I tend to skew toward open source languages these days (or really low cost languages at the very least). PHP, Ruby, Python, Java and JavaScript are all good choices. (Let’s leave frameworks and libraries for another discussion — that’s right, I’m talking to you Node.js). All of these platforms are relatively hot, so kids coming out of school know them, people are interested in coding in these languages and yet there is mindshare around them so that you can build a decent platform doing it. What about proprietary languages, C# or Objective-C? Well, if you are already a heavy Microsoft shop and plan to stay that way, then I’d say have at it with C#. With Objective-C it’s a little more complex, because you are unlikely to write server-side code on the Apple platform. If you want to write iOS applications, then you are going to have to write in Objective-C, but you will also be writing code in at least one other language.
Personally, if I had to start something new today for a “greenfield”, would I code to the Microsoft platform? Probably not.
In summary, I am sure I am going to be flamed all over the place by everybody with an axe to grind for disrespecting their favorite language. Remember, I am not arguing the point that one language is better than another, or that one platform is superior to another. And let’s leave a more detailed discussion of task-specific-solutions, such as “R”, for another day. If it can do the job and you can easily find people to write the code, well, then that’s good enough for me.
But if the only folks that can program in it still remember 300 baud modems, or only five geniuses in the world are familiar with it, then I’d politely suggest that you might want to consider something else.
If I was going to start building something new? Java and C# are fine choices. Ruby seems to be going up and down in popularity, but I’m having lots of fun tinkering with Ruby. My one bias against Ruby is that our hometown of Chicago is the hub of the Ruby-on-Rails mafia — where Ruby is the solution to any problem. Python seems to be on everybody’s short list. Google’s a big Python shop, and all of the things you can do with the Google App Engine integrate easily with Python. Generally speaking, open source tends to be a better choice if you have got a green field because all of your cloud-based platforms are supporting any number of open-source programming stacks.
Just try not to be too far out on the edges.