Several reviewers asked me to compare C++ to other languages. This I have decided against doing. Thereby, I have reaffirmed a long-standing and strongly held view: "Language comparisons are rarely meaningful and even less often fair" . A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness. I do not have the time, and as the designer of C++, my impartiality would never be fully credible.

-- The Design and Evolution of C++(Bjarne Stroustrup)

Do you people agree with his this statement "Language comparisons are rarely meaningful and even less often fair"?

Personally I think that comparing a language X with Y makes sense because it gives many more reasons to love/despise X/Y :-P

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

1

So many hypothetical programming questions go away when coders are forced to think about business side of things. If you re picking a set of language(s) to develop something fresh in, aren't you sort of forced to compare them? Existing experience matters, libraries, stability, future prospects, but language features matter as well, eh? Particularly if shareholders or business folks want to know why you picked A, B and C. If you dare to tell them that Python is no different than assembly, then they will expect you to write functionality in ASM at the same speed.
–
JobNov 27 '10 at 16:10

Underneath this, I think Bjarne is talking about the comparison of C++ with Objective-C and with Eiffel. The languages had completely different design goals, so one kludge might be completely necessary.
–
MacneilNov 29 '10 at 0:26

I think Stroustrup is entirely correct. Adequately comparing two languages on their technical merits requires enough familiarity with both to write idiomatic code and use the same design patterns normally used by programmers who are very productive in both languages. Someone who doesn't have that level of knowledge of both languages may see things that aren't explicitly provided for by the language that he's not as familiar with, and assume there would be problems as a result.

For example, someone who doesn't use Python on a regular basis may assume that Python users regularly have trouble because of indentation. Or someone not familiar with Common Lisp may look at the lack of polished libraries, but not know that the FFI is powerful enough to write wrappers for C libraries with nominal effort. Someone not familiar with Ruby may see the lack of static typing and assume type errors would be a major problem. Finally, someone not familiar with Haskell may see the lack of assignment, and assume it can't handle state.

Now all of this assumes that languages actually are compared only on their technical merits.

I agree with everything except that first sentence. Stroustrup's not well placed to compare C++ to anything because he can never appear to be impartial. However, +1 for saying that you need to know both adequately to properly compare the two.
–
Frank SheararMar 4 '11 at 8:47

A language is a tool. That said, I've seen really, really crappy tools before. No one wants to work with a hammer whose head is liable to fly off and hit another carpenter in the stomach. Likewise, if you noticed your fellow worker's hammer was in that shape, you'd probably steer clear of them when they were using it.

It's also important to really understand which tool it is. You can't use a screwdriver and hammer interchangeably (though some try desperately). Hell you can't even use all hammers interchangeably; you need a sledge for some things, a mallet for others and a tack for yet others. If you use the inappropriate tool, then at best, you'll do a poorer job, at worst you'll injure yourself or a co-worker.

In other words, language comparison is useful in that it can prevent workplace accidents. Taking the above out of metaphor; it's difficult to know without comparing whether a given language is a sledge hammer, a screwdriver, a dremel or a table saw, because (unlike with physical tools) you can't really tell just by glancing. You need to think about the features it offers, see it in action (by trying to read significant pieces of a large codebase written in it), and ideally, test-drive it yourself too. Careful not to make the mistake of just writing Cobol in Python (for example). You need to use the new language idiomatically, which means learning it well. This is probably why Bjarne says most people don't put enough effort in for a useful comparison.

The type of comparison that starts with "I like Blub" and continues with "Well, I like Blub++" is completely useless. If it winds up selecting a language, all it really tells you is who's most persuasive in a given group and/or which language company has the largest advertising budget. If you analyze what a language can do, what tasks its suited for, and where its shortcomings are without resorting to unreasoned arguments or personal bias, then that can be useful indeed.

@Thorbjørn Ravn Andersen: I didn't mix metaphors that badly :p No, but I have used a hammer whose handle was loose (the head did fly off when I swung it the second time; it didn't hit anyone though, just broke a jar). The point is that there is such a thing as a poor hammer, and saying "You shouldn't compare hammers" is only sensible advice if they're all equivalent or interchangeable.
–
InaimathiNov 27 '10 at 18:53

Though, you can tell that a hammer is dangerous, or explain what it should be used for, without resorting to comparisons with other hammers.
–
jhominalNov 27 '10 at 20:53

3

Libraries are more like tools. Languages are like the materials the tools are made out of. We usually prefer both hammers and screwdrivers to be made of steel. And a lot of languages feel like rusted iron, or rubber, or play-doh.
–
MJPJan 10 '11 at 4:43

That, except in some rare (and - rare - as in "it happens once or twice in the lifetime of a solar system") exceptions, it usually leads to language wars, in more or less strong variant, and very rarely leave some practical and useful conclusions.

Languages are tools, not religions. You don't compare a hammer with a screwdriver, but you use the one that fits your task & way of thinking/education/needed level of abstraction the most.
Also, since the one doing the comparison is biased by the fact that he knows at least one of the two, or at least prefers one of the two, it is hard to find a truly objective criteria for comparing them (exceptions exist).

If we treat languages as products and all developers as the marketplace, we can come to a few interesting conclusions:

Products don't always compete. For instance, Haskell doesn't solve the same problems as Java which doesn't solve the same problems as Assembly which doesn't solve the same problems as Prolog. One developer, in different situations, may use all of these languages. Comparison implies competition for superiority. Therefore, it doesn't make any sense to compare languages that don't compete.

Visibility in the marketplace means that the product has already proven itself to be useful to someone. That is, you can compare Ruby and Python all you want - people do it all the time. Somehow, that doesn't seem to change anyone's mind (or if it does, the same number of people change their mind in the other direction). In the ways that matter, Ruby and Python are equivalent. It's like two giant soda companies making "scientific" comparisons of their products. One study shows Coca-cola is superior while the other shows Pepsi is superior. Even if the data is dependable, it doesn't mean anything. We all know they're perfectly good sodas (programming languages) and that one just appeals more or less to my personal taste.

Language comparisons are a form of geek marketing. If there was some perfectly objective place to start a comparison, they might be useful. Of course there's not. Any one that bothers to make a comparison is trying to confirm an existing bias. They're trying to sell a language. Again, if C++ is so bad or VB is so bad or Erlang is so bad, then why are people using them? You can make all the claims you want, but that doesn't stop them from being useful. Our assumption is that people are too dumb to see the truth in front of them, but the truth is likely that the "market" is more complex than we realize. Comparisons tell us more about the person doing the comparison than they do about the products being compared.

Most "language comparisons" are performed with a specific result in mind, which is to "show" that one is "superior" to the other.

Often this means writing a piece of code in both languages and measuring the performance of the generated executable, writing one language highly optimised and the other deliberately for poor performance.
This is how the "Java is slow" myth gets perpetuated. The "tests" to "prove" it are written deliberately to not measure the performance of running Java code but the startup time of the JVM.
Take for example a simple mathematical operation and loop through it 100 times, do that in Java and C++, compile the C++ version with optimisation turned on, the Java version without optimisation flags, then run both executable versions.
The Java class will run far longer than the C++ executable, simply because of the startup time of the JVM.
This shows not that "Java is slow" but that the JVM startup time means Java isn't the proper tool for very short running processes (neither is any interpreted language, or anything else that requires loading of a runtime).
Were the test properly written to run over a period of several hours with both code bases and compiler systems using equivalent levels of optimisation, the results are quite different (probably showing pretty similar performance).