Are Language Comparisons Meaningful? [closed]

Question

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?

Answer 1

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?

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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

Answer 7

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