Take the 2-minute tour ×

Dr Bjarne Stroustrup in his book D&E says

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

What do you people think?

share|improve this question

closed as primarily opinion-based by MichaelT, GlenH7, gnat, jwenting, amon Jul 28 at 20:36


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. –  Job Nov 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. –  Macneil Nov 29 '10 at 0:26

7 Answers 7

up vote 12 down vote accepted

i love comparing programming languages!

i compare java to a warm breeze with a hint of rain

i compare C# to beautiful spring day with just enough fluffy white clouds to keep the sky happy

i compare C to a sledgehammer in a room full of glass

i compare C++ to a bag of sledgehammers in a world of crystal

i compare VB to an old wind-up toy sinking in a bathtub

i compare PL/1 to a rusty anvil, bolted to the floor

what do you compare them to?

share|improve this answer
Love it so far! What about Perl, Python, Ruby, Clojure, Scala, etc? –  Job Nov 27 '10 at 16:05
@Job I compare Perl to a keyboard sneezing. Feel free to add your own in the comments! –  Steven A. Lowe Nov 27 '10 at 16:13
"Lisp is like a bowlful of oatmeal with nail clippings in it." - Larry Wall –  Job Nov 27 '10 at 16:21
"Scheme is an exotic sports car. Fast. Manual transmission. No radio. Emacs Lisp is a 1984 Subaru GL 4WD: 'the car that's always in front of you.' Common Lisp is Howl's Moving Castle." -Steve Yegge –  Inaimathi Nov 27 '10 at 22:34
(Lisp is like (in some ways (at least)) (my grandmother (R.I.P.)) who talked in (interesting (usually (and related))) tangents) –  Steven A. Lowe Nov 28 '10 at 16:57

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

share|improve this answer
Ah, but you should compare a hammer with a screwdriver. How else are you going to know which of the two will help you open your can of paint? –  Frank Shearar Mar 4 '11 at 8:46
@Frank You can use a hammer to open paint? I've been using my car. –  Matt Ellen Mar 4 '11 at 12:32
@Frank - I believe I could open a bucket of paint with both ;) But why bother (it comes with a screw on top anyhow) –  Rook Mar 4 '11 at 15:21

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.

share|improve this answer
You have experienced hammers that can shoot you in the foot? –  user1249 Nov 27 '10 at 15:27
@Thor: a lot of guns have hammers –  Steven A. Lowe Nov 27 '10 at 15:44
@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. –  Inaimathi Nov 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. –  jhominal Nov 27 '10 at 20:53
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. –  MJP Jan 10 '11 at 4:43

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.

share|improve this answer
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 Shearar Mar 4 '11 at 8:47

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

  1. 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.
  2. 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.
  3. 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.
share|improve this answer

Stroustrup is completely correct.

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

And that's just one example (which I happen to be familiar with).

share|improve this answer

As a project manager, you have to make some comparisons for choosing the language in which your software will be coded. Criteria may not be technical:

  • Is the language adequate for the task
  • Is the language available on all the target platforms
  • Quality, reliability and cost of compilers
  • Are there available programmers who know that language, are they competent, expensive, creative
share|improve this answer
Though there may be fewer programmers who are familiar with newer, more advanced languages, they tend to be highly capable. –  kevin cline Mar 4 '11 at 8:54
