views:

6674

answers:

14

Does anybody know of any research or benchmarks of how long it takes to develop the same application in a variety of languages? Really I'm looking for Java vs. C++ but any comparisons would be useful. I have the feeling there is a section in Code Complete about this but my copy is at work.

Edit:

There are a lot of interesting answers to this question but it seems like there is a lack of really good research. I have made a proposal over at meta about this problem.

+11  A: 

This article(a pdf) has some benchmarks (note that it's from 2000) between C, C++, Perl, Java, Perl, Python, Rexx and Tcl.

Some common wisdom I believe holds true (also somewhere within the article):

The number of lines written per hour is independent of the language
ChristopheD
...but how much those lines achieve is dependent on the language.
sundar
+8  A: 

Opinion: more important is what is faster for a given developer, for example yourself. What you are used to, will usually be faster. If you are used to 20 years of C++ pitfalls and never skip an uninitialized variable, that will be faster than Java for anybody.

If you remember all parameters of CreateWindowEx() by heart, it will be faster than MFC or winforms.

Pavel Radzivilovsky
Sure, and if you don't know how to turn on the oven, then starting a fire by rubbing sticks together will be faster. I think what he's looking for is something like "given equivalent experience, what's the distribution of performance?". My oven example isn't unique to the physical world: I know hackers who struggled with Perl for years, and then picked up Python and became more productive with that in a weekend.
Ken
I know experience and skill are difficult to control for but, yes, I'm looking for some empirical studies which attempt to abstract that away.
stimms
As I say, both questions are legitimate. One is purely academic related to the value of the languages, the other is what a manager should actually be asking in the real world.
Pavel Radzivilovsky
+4  A: 

It would make more sense to benchmark the programmers, not the languages. The time to write a program in any mainstream language depends more on the ability of the programmer in that language than on qualities of that specific language.

Mark Byers
+1  A: 

Most programs have to interface with some other framework. It tends to be a good idea to pick the language that has libraries specifically for what you are trying to do. For instance are you trying to build a distributed redundant messaging system? If so I would use Erlang. Are you trying to make a quick and dirty data driven website, use Ruby and Rails. You get the idea. Real time DirectX where performance is key, C++/C/Asm.

If you are writing something that is algorithm based I would look to a functional language like Haskell, although it has a very high learning curve.

Jonathan Fischoff
+3  A: 

I think most benchmarks and statements on this topic will mean very little.

Benchmarks can always be gamed; see the history of "Pet Store".

A language that's good at solving one kind of problem might not apply as well to another.

What matters most is the skill of your team, its knowledge of a particular technology, and how well you know the domain you're trying to solve.

UPDATE: Control software for jet engines and helicopters is a very specialized subset of computing problems. It's characterized by very rigorous, complete, detailed specs and QA that means the multi-million dollar aircraft cannot crash.

I can second the (very good) citation by John Strohm of Pratt & Whitney control software written in Ada. The control software for Kaman helicopters sold to Australia was also written in Ada.

But this does not lead to the conclusion that if you decided to write your next web site in Ada that you'd have higher productivity and fewer defects than you would if you chose C# or Java or Python or Ruby. All languages are not equally good in all problem domains.

duffymo
+30  A: 

Pratt & Whitney, purveyors of jet engines for civilian and military applications, did a study on this many years ago, without actually intending to do the study.

They went on the same metrics kick everyone else went on in the 1990s. They collected a bunch of data about their jet engine controller projects, including timecard data. They crunched it. The poor sap who got to crunch the data noticed something in the results: the military projects uniformly had twice the programmer productivity and one/fourth the defect density as the civilian projects.

This, by itself, is significant. It means you only need half as many programmers, and you aren't going to spend quite as much time fixing bugs. What is even more important is that this was an apples-to-apples comparison. A jet engine controller is a jet engine controller.

He then went looking for candidate explanations. All of the usual candidates: individual experience, team size, toolsets, software processes, requirements stability, everything, were trotted out, and they were ruled out when it was seen that the story on those items was uniformly the same on both sides of the aisle. At the end of the day, only one statistically significant difference showed up.

The civilian projects were written in every language you could think of. The military projects were all written in Ada.

IN EVERY SINGLE CASE, against every other comer, for jet engine controllers at Pratt & Whitney, using Ada gave double the productivity and one/fourth the defect density.

I know what the flying code monkeys are going to say. "You can do good work in any language." In theory, that's true. In practice, however, it appears that, at least at Pratt & Whitney, language made a difference.

Last I heard about this, Pratt & Whitney upper management decreed that ALL jet engine controller projects would be done in Ada.

No, I don't have a citation. No paper was ever written. My source on this story was the poor sap who crunched the numbers.

This, incidentally, was BEFORE Boeing did the 777, and BEFORE the 777 brake subcontractor story happened. But that's another story.

John R. Strohm
I'd be interested to hear if any of the civilian efforts used Ada, and whether their performance was consistent with the military side.
Carl Smotricz
There is a brake subcontractor story? Do tell.
stimms
Ken
I don't expect you'd want to write jet engine controllers in python or java - but what language(s) were the civilian teams using ?
nos
duffymo
@John R. Strohm - Great story. If it were that clear cut, what reason can you offer for why Ada has had such poor adoption in the rest of the marketplace? It might also have to do with the kind of problem you're solving. A real-time problem like jet engine controls isn't something you'd do with Java or C#. Likewise, I'm not sure that Ada would anybody's first choice for web app. That's why any case study is suspect, because all languages are not equal for all problems.
duffymo
@John - +1 from me. An excellent story, well written.
duffymo
Ada aaahhhhh!!! (pulling out my eyeballs)
0A0D
According to http://www.adaic.org/atwork/pw.html the only comparison was to **assembler** so Ada is more productive with less defects than assembler? Shocker!
cletus
@Cletus, the AdaIC piece doesn't tell the full story. Read Duffymo's comment a few lines higher.
John R. Strohm
The big question in such stories is - was Ada a better language, or was Ada team a better team? It's said to be "ruled out", but it's not trivial how you would rule that out. This calls for double blind test...
ima
"No, I don't have a citation." that's also very characteristic for such strong claims
ima
@duffymo, the best answer to your "why such poor adaptation" question is found in Changeling's comment. There apparently are a lot of people in the United States who have bought into the "bondage-and-discipline language" meme. (The same is not true in Europe, where Ada is used heavily in many disciplines.)
John R. Strohm
@ima, this was NOT a one-shot study, for the purpose of studying Ada vs. anything else. This was a data-mining exercise, looking at metrics from LOTS of projects, several in Ada, several in other languages, and lots of teams, aimed at seeing what, if anything, the metrics showed. An interesting anomaly showed up in the data, and the guy doing the numbercrunching started digging. Recall that "Scientific progress starts not with 'Eureka!', but with 'That's funny...'".
John R. Strohm
No, Changeling's response isn't the last word. I don't know what "used heavily" means, either. I can't believe that if Ada was that superior in all applications that it wouldn't be used. If that data were true and as widely known as you claim, I'd have a hard time seeing why Google would not be embracing Ada as one of its supported languages or Microsoft would not be beating the drum for Visual Ada. There's something else missing here, and either you don't know or you're not telling. I'll Google for Ada libraries and see what comes back.
duffymo
Stuff for Ada 95. Did this language stop in its tracks 15 years ago? http://www.google.com/Top/Computers/Programming/Languages/Ada/Bindings_and_Libraries/
duffymo
duffymo
@JRS, can you provide link or name of that study, please? It would be very interesting read, this argument aside.
ima
@JRS Otherwise, there are many common traps in such investigations, which prevents me from taking strong claims seriously while not being able to read and evaluate original article. The range of potential catches is huge - starting from metrics and statistics used, on to the selection bias (it's easy to include some really bad project into 'anything else' part to make average plummet), on to the placebo effect (it's well known that productivity increases temporarily after almost _any_ change), etc
ima
And there still is a known bias for Ada in aerospace and defense, owing to the history of this language, so there are reasons of being suspicious.
ima
+2  A: 

A couple of anecdotal data points:

On Project Euler, which invites programming solutions to mathematical problems,

  • the shortest solutions are almost invariably written in J or K, a relative of APL; there are occasionally MatLab solutions in the same range. It can be argued, though, that these languages specialized in math.
  • runners up were Ruby solutions. A lot of algorithm can be wrapped in very little code, and it's much more legible than J / K.
  • Python and Haskell solutions also did very well, LOC-wise.

The question asked about "fastest development," not "shortest code." But it's conceivable that shorter solutions are faster to come up with - certainly for slow typists!


There's an annual competition among roboticists. Contestants are given some specs for some hardware, a practical problem to solve in software, and limited time to do so. Again very domain specific, of course. Programmers have their choice of tools, including language of course. Every year, the winning team (often a single person) used Forth.


This admittedly limited sample suggests that "development speed" and "effect of language on speed" is often very dependent on the problem domain.

Carl Smotricz
I think some of those results may not be directly related to language, though. *In my personal experience*, I've found that programmers experienced in languages like Haskell, Forth, etc., tend to be more talented overall than other programmers; likewise, smart programmers tend not to use languages like C, C++, etc., for "fun" problems like Project Eulers, even though they would probably be as successful with those languages.
mipadi
A: 

According to Norvig, Lutz Prechelt published just such an article in the October 1999 CACM: "Comparing Java vs. C/C++ Efficiency Issues to Interpersonal Issues".

Norvig includes a link to that article. Unfortunately, the ACM, despite having a bitmap graphic proclaiming their goal of "Advancing Computing as a Science & Profession", couldn't figure out how to maintain stable links on their webpage, so it's just a 404 now. Perhaps your local library could help you out.

Ken
I found that article at http://portal.acm.org/citation.cfm?id=317683, however it only examines memory usage and runtime
stimms
It's kind of old, too. It's using GCC2.7 and JDK1.2. I bet things are quite different by now.
wbkang
+17  A: 

One of the few funded scientific studies that I'm aware of on cross-language productivity, from the early 90s, funded by ARPA and the ONR,

We describe the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center (NSWC) requirement for a Geometric Region Server. The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the..

Don Stewart
I came in here just to post this link!
Edward Kmett
How does a 1994 study help with someone making a decision that includes Java or C#?
duffymo
@duffymo: He said Java vs C++.. this study is still relevant
0A0D
Java in 1994? http://en.wikipedia.org/wiki/Java_version_history#JDK_1.0_.28January_23.2C_1996.29
duffymo
@duffymo the OP clearly says "any research .. any comparisons would be useful", and this is one of the very few research projects to do such a comparison.
Don Stewart
It's true that the paper has the word C++ in it, but that's where its relevance stops: the C++ language of 1994 was not standardized, exceptions and templates had just been added in, there was no STL, there was no Boost.
rpg
+5  A: 

See also

http://stackoverflow.com/questions/354124/are-there-statistical-studies-that-indicates-that-python-is-more-productive

for some discussions about this kind of question.

Brian
+1  A: 

This question is a little old fashioned. Focusing on development time solely based on the choice of language is of limited value. There are so many other factors that have equal or more impact than the language itself:

  1. The libraries or frameworks available / used.
  2. The level of quality required (ie. defect count).
  3. The type of application (eg. GUI, server, driver etc...)
  4. The level of maintainability required.
  5. Developer experience in the language.
  6. The platform or OS the application is built on.

As an example, many would say Java is the better choice over C++ to build enterprise (line of business) applications. This is not normally because of the language itself, but instead it is perceived that Java has better (or more mature) web server and database frameworks available to it. This may or may not be true, but that is beside the point.

You may even find that the building an application using the same language on different operating systems or platforms gives greatly differing development time. For example using C++ on Linux to build a GUI application may take longer than a Windows based GUI application using C++ because of less extensive and mature GUI libraries avaialble on Linux (once again this is debatable).

Ash
A: 

That Ada story might be an embellished version of this: http://www.adaic.com/whyada/ada-vs-c/cada%5Fart.html

no
Rational - no, they didn't have bias in favor of Ada, did they? 8)
duffymo
A: 

Erlang vs C++/Corba

"... As the Erlang DCC is less than a quarter of the size of a similar C++/CORBA implementation, the product development in Erlang should be fast, and the code maintainable. We conclude that Erlang and associated libraries are suitable for the rapid development of maintainable and highly reliable distributed products."

Paper here

puzza007
A: 

There's a reason why there are no real comparisons in that aspect, except for anecdotal evidence (which can be found in favor of almost any language).

Actually writing code takes relatively small portion of developer's time. Even if language lets you cut coding time in half, it will be barely noticeable by the time project ends. Design, structure of program, development process are all much more important, and then there are libraries, tools and experience with them.

Some languages are better suited for certain development processes than the others, so if you've settled on design and process you can decide which language will be more efficient - but not before.

(didn't notice there's a similar answer already, so feel free to ignore this)

ima
I disagree. Language affects the design of the program, the amount of time it takes to debug and the flexibility to change your design. It does make a difference.
Casebash