@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.

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.

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.