How to Choose a Programming Language

Making sound investments in a bubble

Choosing a programming language for your company is a strategic decision with long-term implications for hiring, culture and even the viability of your product. This article looks at what you should be considering when making your selection and who should be involved in the decision making process.

With the proliferation of JVM languages, the opening up of Microsoft languages and tools, the critical rehabilitation of the functional programming paradigm, and the latest attempts to supplant C for embedded devices and real time, the last decade has seen an explosion in the number of programming languages that can be seen as commercially viable. This increase is closely linked with the decline in homogeneous application stacks, where one programming language is used throughout an application or company.

For those who were left bored and frustrated by the ten-year Java/.NET duopoly on corporate programming languages, this change is both welcome and overdue. To others, it looks alarmingly like a bubble. How many functional JVM languages, compile-to-JavaScript languages or C replacements can the skills market support long-term? Probably fewer than the developers can manage already.

In some respects, it is futile to try and recommend which of the available languages is best for your company and product — almost any vaguely mainstream language can be made to work for the majority of internet hosted applications — and there will be no shortage of recommendations on which one to choose. If you find yourself here because your development team is lobbying for a new language or, you have heard that another company is having success with a language you’re not familiar with, then you’re not alone.

Although the below criteria are largely interlinked, once you’ve shortlisted the languages you’re interested in, you need to consider:

• Existing languages used at your company;
• Internal skills and culture;
• Stakeholders;
• Local skills market;
• Productivity;
• Language ecosystem and support; and
• Novelty and longevity of the language.

Existing languages

If you already have working code for your product (in one or more languages) and are considering using a different language for a new feature or component, you need to ask yourself if this is necessary or whether one of your existing languages already does what you need. You may have been told that X language is Y% more efficient to develop in than your existing language, but can that actually be quantified? And will the efficiency benefits outweigh the total cost of retooling, rewriting, retraining and hiring.

If the argument for change is feature or paradigm-based, first, and it may seem obvious, check whether any of your existing languages provide those features or cannot at least simulate the required paradigm. If however, the languages are becoming obsolete, work through the other checklist criteria to test sustainability before making a decision about future language changes.

Internal skills and culture

If you already have a development team in place, consider whether they’re ready and able to adopt a new programming language. Some developers will be excited, some will be nervous about the prospect of change and some might perceive the change as an attempt to force them out of the company. The only way to find out is to ask them how they’re feeling.

If they’re not supportive of the choice of new language, unfortunately, that’s likely to be the end of the road for the new language. ‘Concerns’ have a nasty habit of becoming self-fulfilling prophecies, especially if your team has factions or disruptive individuals and one of them is sponsoring the new language. In this case, you’d be better off focusing time and energy on improving team dynamics and collaboration than you would pushing programming changes.

Stakeholders

Two questions: first, who has a stake in which programming languages you use and second, do they have an agenda? If you are a larger company and no longer have day-to-day interactions with your development team, you may have to apply a degree of professional scepticism when your development team propose new languages. In an ideal world, they’ll be thinking solely in terms of company interests and products, but reality may mean short-sighted adoption of a new ‘tool’ to resolve an isolated issue or even CV-bolstering for those looking to jump ship. It’s unpleasant to look at it this way, but it’s better than learning the hard way.

It is also worth considering the impact on other departments, especially HR. Your HR team might have established relationships with local recruiters or universities, or appear at careers fairs on the basis that your company uses a particular language. Rebuilding all those relationships will be time consuming so make sure they are consulted before any changes are made.

Local skills market

At some point you will need to hire developers with experience in your new language. If you have no senior developers who consider themselves expert and willing to coach others, you will need to hire right away — or reconsider your choice of language.

There are a number of ways to check whether or not your local catchment area can provide you with the talent you need:

1. Are other companies in your area advertising for the same languages? Are the job postings left up for months on end? If posts aren’t being filled by your competitors, then it’s likely you will have trouble too.
2. If you’re based in a city with a meet-up culture, is there a meet-up for your new language? If so, go along and talk to some of the attendees.
3. Do your local university give graduates the general skills and exposure to the paradigms they need to work in your chosen language or are they taught specific, unsuitable languages?

You’ll also need to look at the financial side, if you’re moving from a homogeneous code-base with specialist single-language developers to needing (generally more expensive) ‘polyglot’ developers, you’re going to have to dig deep.

Productivity

Measuring developer productivity and efficiency is a complex and controversial topic (and outside the scope of this article) but it’s worth remembering that productivity is the most important consideration when selecting a new language.

Put generally, given equal skills in two languages, how quickly can the average developer in your company finish an average task in each language to an acceptable level of quality. Unfortunately, this question is practically impossible to answer objectively — bake-offs and other tests to compare two languages are very hard to make fair and prone to agenda-based gaming by the participants. The more practical question is this: do you think your development team is currently productive? If the answer is yes, do you really want to risk destabilising that?

If the answer is no, is the current programming language actually the main problem? If you are being lobbied by your developers to switch, they need to shoulder some of the responsibility for the language change and prove its worth by agreeing to ‘before and after’ productivity tracking. If the promised gains are not delivered, it should be made clear that trust has been lost and you’ll be less likely to accept their recommendations in the future.

Ecosystem and support

Compared to the other criteria mentioned above, this is relatively easy to quantify for any language.

• How many Stack Overflow questions relate to your language, how quickly are they answered and how many answers are offered?
• Is there a IDE with dedicated support for your language? When was it last updated?
• Identify some widely used third-party libraries for your language and check when they were updated.
• How many GitHub projects are written in your language?
• If you use a platform- or function-as-a-service model for hosting, is your language supported?

Of these, the trends on Stack Overflow are most interesting as they can be used to plot the uptake of your language and can also help assess your language against the final criterion.

Novelty and longevity

The question of whether or not a language will be around in ten years’ time is generally moot, as the answer will be yes. Even the most niche language will find a following of ‘die-hards’ and be supported indefinitely. Rather, the question is whether you will be able to apply all of the above checklist to your language in ten years’ time and still get positive results? And it really depends on how new it actually is. Many languages that are considered ‘new’ by corporate standards are surprisingly mature — Go and Clojure are over seven years old, for example.

If the language you’re considering is less than two years old, you are taking a big risk in adopting it. At this stage it is likely to be ‘creator’-led, with the original author of the language providing the majority of support. As such, it remains a possibility that the author may simply lose interest and walk away. When a programming language is at least five years old, you should be able to start predicting its trajectory. If there’s been little traction (measured by ecosystem and support above), it’s unlikely there’ll be a breakthrough and the language is probably destined to be a niche language or fade away. There are of course notable exceptions — all of the functional languages were revisited when the paradigm became popular.

At the other end of the spectrum, veteran languages over 20 years old should also be treated with caution. They usually need a large number of libraries to provide basic functionality (built-in to modern languages), may have had their syntaxes mangled with bolt-on additions or, quite simply, no longer be attractive to younger developers.

Carefully considering these factors before choosing a new language will ensure that any switch is done purposefully and that if you do decide to make the move, that it will be the right decision for you, your team and the company.

*******************************************************************

Ben Halstead is a consultant CTO and writing as a contributor for CTO Craft.

If you, or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, visit: www.ctocraft.com or contact us via email at: info@ctocraft.com

Subscribe here to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more…