I am looking for a methodology for choosing a language. I am not asking for opinions about languages. I have been tasked with the process of comparing our shop's current language with others that are available. We are a web development shop btw.

Our CEO would like a full white paper about all web based languages that are available, What parent language they are derivatives of (e.g jsp is from java which is from c/c++). I need to create a matrix with all the key factors of a particular language as well and the short comings of that given language. Is the language limited by platform, is it designed for functional programming, procedural or OO or can it be used with any programming paradigm?

I also need to have information less technical, like the size of the talent pool for a given language and the median salary in that pool. How will the marketplace view our choice?

We started looking for a consultant to help us understand all of these things but what we have found it that most consultants are coming from a development background and often it seems that the answer is "xxx is the best language because it is the one that I have used the most over the last n years and it has never let me down. You could Supplement it with yyy for front end and use zzz library"

I am feeling overwhelmed with this task and I feel like the best course of action, given what our CEO is looking for, is to look in the world of academia and hire a professor with no actual development experience to come in and "teach" us about all possible languages.

Has anyone else had to go through this exercise? If you have can you share the steps and/or methodology you used to go through the process?

  • 21
    Does the CEO actually plan to use this matrix to decide things such as "We will use ${language} to build ${nextBigProject}!" To build something that might actually be useful for this (though I'm not sure it will ever be seriously useful) would probably take a significant amount of time, and there would be ongoing maintenance on it as well. Commented Oct 8, 2014 at 17:22
  • 3
    I think a general guide to choose a language/environment for a project might be to first try to get a deeper understanding of the specific problem that the project is trying to solve (in a language-agnostic way), look for tools/libraries that best help solve it at that time, then look at what languages you need to know to work with those tools/libraries. That will probably give you shortlist of languages, and from there you can winnow it down based on your familiarity with them, vendor support, budget, etc... Commented Oct 8, 2014 at 17:25
  • 9
    The very first question to answer is, "do we need to change at all?" What problems are not being solved by your current choice of language?
    – John Bode
    Commented Oct 8, 2014 at 17:31
  • 4
    How can Stack Overflow help developers evaluate technologies? "This morning I had about 8 frameworks in front of me, trying to decide which one I'll use..."
    – gnat
    Commented Oct 8, 2014 at 17:54
  • 7
    In practice you might as well throw darts. In the web arena (especially JavaScript, et al) there are dozens (if not hundreds) of options, with assorted strengths, weaknesses, affinities, and incompatibilities. You can analyze it to death, or just make an educated guess, go forward, and do a mid-course correction if needed. Commented Oct 8, 2014 at 22:01

4 Answers 4


@FrustratedWithFormsDesigner hinted at this above, I'll be more blunt: you've been charged with a expensive but useless task.

I suspect the CEO is looking for irrefutable, objective evidence which will support his choice of language. The problem is that preference of language is loaded with far too many subjective and extrinsic factors for the white-paper to be meaningful let alone useful.

Put another way, if there were an ideal language, everyone would be using it instead of those "objectively" defective languages. It also bespeaks a degree of micromanagement that ought be the province of the engineers who will have to make it work. Erlang might be the "objectively best" but if no one knows it, add a 6 month/engineer start up cost and 6 more month / engineer to gain competency.

Since I don't have your job, I'm not worried about losing it, although you may. I'd give the CEO a paper on the Physical Church-Turing Thesis. I'd then get together with the senior engineers and get their non-rigorous, non-objective opinion as to what should be used and tell the CEO that's what you shall use. In exchange you'll promise the engineers will keep out of board meetings, CFOs, Accountancy Methods, selection of VPs and so on. There is a reason we specialize, and he has no more place in engineering preferences than you do in his domain.

  • 6
    Ha, I love the reckless enthusiasm of the last paragraph. I would say it is the CEOs domain because of that pesky 6 months you mentioned, which is all you need to tell him/her imho.
    – Nathan
    Commented Oct 8, 2014 at 23:19
  • 1
    "Physical Church-Turing Thesis" Let's not go there. Very few programming languages have a formal semantics, pretty much a prerequisite for it to be Turing complete. (Without one, it isn't even a model of computation.)
    – Rhymoid
    Commented Oct 9, 2014 at 0:40
  • 4
    Just choose Lisp and be done with it.
    – Eric
    Commented Oct 9, 2014 at 14:23
  • 1
    By Lisp, you mean ClojureScript of course. :-) Commented Oct 9, 2014 at 14:54
  • 1
    +1. It's your job as an engineer to convey to a CEO why this is not a good approach. This may be hard because it kind of looks like a good approach, but it's necessary.
    – djechlin
    Commented Oct 9, 2014 at 17:34

Some broad brush strokes to consider:

Language popularity

This really shouldn't matter, because popularity does not necessarily equate with productivity, expressiveness or any of the other language qualities that matter more, but this consideration often trumps all other considerations because:

  1. It's easier to find software developers in a popular language.
  2. It's easier to find tools and libraries in a popular language.
  3. Decision makers don't understand language tradeoffs, so they'll make the safe decision ("many companies use this language, so it must be good").

Applicability to the problem domain

Any program can be written in any Turing-complete programming language, but some languages are better suited for certain problem domains than others. If you're writing web applications, you probably will gravitate to languages and tools that are well-suited for that, and they most likely will be object-oriented languages.

On the other hand, if you're going to be writing software that's primarily research-based or math-based, you will probably gravitate towards languages that embrace functional paradigms.

And, of course, there's everything in between. Many languages support multiple paradigms, and some software patterns exist solely to overcome limitations in those languages that lack certain features or paradigms.

Expressiveness and productivity

Some languages are more expressive than others. What can be written in one language using a thousand lines of code can be written in a more expressive language using a hundred lines of code. The tradeoff is that the hundred lines of code is probably written in a less popular language, by people with greater expertise.

A lot of the lines of code present in object-oriented languages used to write line-of-business applications are ceremony. This ceremony, while costing time and effort to develop, also provides a visible structure that wouldn't otherwise be readily apparent in a more expressive language. It allows people with less expertise than they would otherwise need to work on the code with a reduced amount of risk.

The era of multiple languages

I'll conclude by asserting that the desire to decide on a single language may be a false dilemma. Applications today are often written, not in one, but in many languages. Each language has its own strengths, and (in theory) is specifically designed for the task it is being used. Some problem domains (such as web browser logic or database access) require specific languages.

  • 7
    I would add to the last point that if you want to use multiple languages, it could be useful to consider a platform that supports easy interoperation between them (.Net CLR or JVM).
    – svick
    Commented Oct 8, 2014 at 18:08
  • 9
    @NathanCooper: You mean you've never written a web application? Even a small one? Or had to port a mobile app to multiple platforms? Or worked in embedded? Or retrieved data from a SQL database? Commented Oct 8, 2014 at 23:25
  • 10
    @NPSF3000: Naturally, you didn't bother to disclose your method of sorcery. I call shenanigans. Commented Oct 9, 2014 at 1:19
  • 9
    @NPSF3000 While C# may be a good choice for what you do (though using Unity certainly stretches things a bit since it's explicitly designed for them to do all the multi-language heavy lifting for you), your one anecdote does not rebut the point. Certainly most non-trivial projects are multi-language in the sense that they use SQL and another technology, but even beyond that, many use different programming languages in parallel, or write their application in one language and their tools in another, etc. I do not find the assertion contentious at all. Commented Oct 9, 2014 at 2:59
  • 7
    @NPSF3000 If that's your problem with it, then say that. Don't make us go through this rigmarole of trying to figure out what you mean. I'm sure Robert would be happy to make an edit if you had stated outright "I disagree that some problem domains require specific languages". That said, I see no implication at all here that working in multiple languages is "beneficial by default". Commented Oct 9, 2014 at 5:04

There are business reasons for choosing a language, and there are engineering reasons for choosing a language, and the twain do not always meet. Throwing in academic reasons is likely to make things worse. I doubt a professor will be able to help you in the way you need.

The facts about a language's ancestry and features are pretty easy to find. You could probably spend a day on wikipedia to fill most of that out. Talent pool size and salary are more difficult, because most people don't consider themselves single-language programmers. Companies who use less popular languages like Scala pretty much expect to hire good general programmers who don't have language-specific experience. Judging from some presentations I've seen, that strategy seems to have worked out well.

Even knowing the facts still leaves you with a pretty subjective choice. Your CEO is going to want it boiled down to a rough metric something like dollars per feature. To get an accurate picture, you're going to have to do some prototypes, then talk about how easy it was to learn, how fast it was to write a prototype once you learned the basics, how easy you think it would be to maintain, and how broadly applicable you think it would be to the kind of work you typically do.

Rather than trying to cover all languages, I would seek to get representatives from the different programming paradigms and types of frameworks, and implement a prototype in each.

Here's a rough list of back end categories:

  • Microsoft. (May have subcategories. I know nothing about them.)
  • Heavyweight OOP, like Drupal.
  • Lightweight OOP, like python bottle.
  • Play/lift/scalatra using Scala.
  • Play/lift using Java.
  • Spring-like.
  • Struts-like.
  • Rails-like.
  • Haskell-based.
  • Node.js

On the front end:

  • OOP-style JavaScript
  • Functional-style JavaScript, like with Underscore
  • Reactive-style JavaScript, like with Bacon
  • Google Web Toolkit
  • Elm

Spending a day or two on each category, implementing a simple prototype, would take you a couple months, after which you would have a much better idea of the strengths and weaknesses of each. Perhaps you could rule some out more quickly based on your company's culture or experience.

Since this is a business report, I would also take some time googling things like "What language does <company> use," substituting various companies you admire. Many of them have written whitepapers of their own on why they made specific language choices, which would make excellent references for you to include.


Identify and cost the shortcomings inherent to your existing development process as $A. Identify the cost of switching to any other development process as $B.

If $A is less then $B, stop.

If your known shortcomings outweigh the cost of change (and that is a big if!) then analyse the shortcomings in detail and start looking for a language/development environment/development process changes that addresses them, one that wont introduce other more expensive problems.

To be honest, unless you are currently trying to develop web apps in Fortran, then the only impact the language you use will have is on the cost of contractors you use to fill the gaps. Main stream and mature languges/tools/development processes have already solved most of the problems you are likely to face where as the hottest, newest and sexiest tools come with the most expensive trainers and contractors, but the least mature solutions. And if you do have shortcomings that warrant such a change, it is unlikely that your choice of language will fully address them.

However, if profitability is not the primary objective here then you need to factor in the the stigma of being considered old-fashioned against the kudos of being cutting edge. Ask your boss for the dollar values to use for this part of the equation.


Not the answer you're looking for? Browse other questions tagged or ask your own question.