One of our development team’s current projects is porting our network of web sites from Classic ASP to ASP.NET. All of our current scripts and apps are written in VBScript (of course), so when switching to ASP.NET, the obvious choice is to use VB.NET, right? I mean, our team already knows VB syntax and, as a result, we would find it easier to learn VB.NET.

That’s not the only thing that matters, though. The architectural differences between Classic ASP and ASP.NET are significant enough that knowing VBScript won’t in itself help us be great VB.NET programmers.

VB.NET and C# actually share a lot of similarities in terms of functionality. But that doesn’t make them identical. Google Trends tells me that, as of this writing, C# is 3 times as popular as VB.NET. That translates into a lot of extra resources for learning and troubleshooting.

This signifies the importance of hiring versatile programmers over <insert language here> programmers. With the latter, then you almost have no choice when refactoring; you’re pretty much forced to use the same (or similar) language, even when another language may be more appropriate for the job at hand.

The hard part about picking a language for a new project is determining if it’s the right tool for the job. That means figuring out the advantages and disadvantages of each reasonable option.

In our case, picking VB.NET over C# means that our team will probably be able to pick it up faster, and we’ll be able to get a version of our system released sooner. Yes that’s a very clear benefit, but using that as the only criterion to make the decision is akin to taking a loan without first asking about the rate of interest.

According to Alan Kay, the right language alone is not good enough. Language adoption is almost as much about marketing as anything else.

Let’s say the adoption of programming languages has very often been somewhat accidental, and the emphasis has very often been on how easy it is to implement the programming language rather than on its actual merits and features. For instance, Basic would never have surfaced because there was always a language better than Basic for that purpose. That language was Joss, which predated Basic and was beautiful. But Basic happened to be on a GE timesharing system that was done by Dartmouth, and when GE decided to franchise that, it started spreading Basic around just because it was there, not because it had any intrinsic merits whatsoever.

PHP is another example. I was talking to a former colleague of mine the other day about how easy it was for me to just start coding with PHP. Because it’s such a popular language, there are a lot of libraries and resources out there to do a wide variety of simple things. Its popularity also results in the community around it growing even further, which some might classify as progress:

There was a tight feedback loop as increased knowledge enabled us to discover and manufacture more tools, and these tools allowed us to discover and learn more knowledge, and both the tools and knowledge made our lives easier and longer. The general enlargement of knowledge and comfort and choices – and the sense of well-being – was called progress.

Of course, PHP gets its fair share of detractors, so I’m not even going to try to argue about how great or terrible it is. All I’m saying is that the fact that it’s popular carries with it some benefit.

Picking a popular language can reduce time to market, which may determine whether or not the project will succeed, while picking a maintainable language may allow you to last longer in that market. But if you pick too niche a language, it will be hard to find programmers who are skilled in that development environment, which means you’ll end up paying more for experience and/or training.

This is a decision that needs to be made at the project level, and it needs to be made with the right information, not just the information that’s easiest to gather.