Programmer productivity by programming language?

Question

In code complete, there's a nice table listing how productive a programmer is depending on language. Jeff Atwood has a nice blog post about it. This chart is at least 4 years old by now. I'm curious: have there been any more recent studies done on this?

(insert standard anti-flamewar boilerplate here... we're all adults)

Update: I appreciate everyone's opinions on the subject and whether or not this is a relevant question or not. But that's not really what I'm asking for. I'm wanting any studies on the subject. I'm inclined to agree with most of the opinions posted thus far, but I'd like to see if there's any research to back that up.

And I'm also aware that choice of programming language is a complicated subject that depends on other factors like developer familiarity. To me, this is all the more reason to have these kinds of discussions backed by research.

Also, thanks for the link, Robert Gamble.

Answer 1

The link doesn't show how productive a coder is, it shows how many LOC it took the author to perform the same task in various languages. Typing is a trivial part of coding.

Answer 2

I wonder how APL fares on this study.

X[⍋X+.≠' ';]

-- sort a list of words according to word length.

(∼R∈R°.×R)/R←1↓ιR

-- find all primes between 1 and R.

Answer 3

That's an interesting idea. I am fluent (and use weekly) C#, VB.NET, MFC C++, Delphi and Objective-C. I would say each have their strengths and weaknesses. Personally, I think it's the developer not the language that counts in productivity. I'm know C# way better than MFC, so am more productive in C#.

Having said that, I find for example that using C# 3.0, I am more productive than 2.0 using the new language features. Also, would someone using vanilla ASP.NET be more or less productive than someone using ASP.NET MVC and would it come under the banner of the same language?

I think @MusiGenesis is right - it's more of a platform, or methodology thing these days, rather than straight language.

Answer 4

The table in Code Complete, and reproduced in the blog post you cited, does not plot programmer productivity but rather average LOC ratios. While the expressiveness of a language can certainly be related to programmer productivity it probably isn't fair to say that just because it takes 5 times as many lines of code in languages X than language Y that programmers using language X are 5 times as productive than language Y. There are many factors of a language that can influence productivity including language size and complexity, maintainability, ease of debugging, etc.

The metric you should look at is how long it takes to solve a given problem in a certain language compared to other languages for a given problem domain, recognizing that some problems can be solved more productively in one language than another for one domain and vice-versa in another domain, i.e. The Right Tool for the Right Job. That said, this paper does a good job outlining a method and metrics for determining programmer efficiency in different languages.

Answer 5

I agree that LOC isn't a good example of programmer productivity, but of language expressiveness in the hands of an expert in a language. An expert in Python or Common Lisp can make a very short piece of code do amazing things. But an expert in C++ can do the same (albeit not as briefly). The C++ code will likely run faster though.

Also, a very expressive language, like Common Lisp, can produce very brief code using macros but that code can be challenging to decipher later (even by the original programmer) unless you are one of a very small group of people who are really good Lisp hackers.

Additionally, programmer productivity has a lot to do with what tool you are used to versus learning for the first time. I can write code fairly quickly in Delphi or VB that does something useful, but now that I am learning Python w/Django it's going slowly because I'm out of my element (and this whole web development thing is new to me too).

Answer 6

IIRC, in Software Engineering Economics, Boehm notes that productivity varies by two orders of magnitude among people using the same tools.

The "productivity adjustment factor" in the COCOMO estimator is the single biggest influence on overall cost and schedule -- and it's an assessment of team productivity independent of tools.

Productivity is entirely related to a person's skill, knowledge, training, work-ethic, luck, and drinking habits. It has little or no relationship with language or tool.

Answer 7

I would argue that a programmers skillz are a better predictor of their productivity than the programming language they use.

Answer 8

http://norvig.com/java-lisp.html

Answer 9

As others have said, it shows how many lines of code are required to implement a simple task in various languages, which is not the same as "which language is a programmer most productive in".

Anyway, just for kicks, let's fill in a few blanks. Here's the most concise C++ implementation I can think of:

#include <iostream>
#include <fstream>
int main(){
    std::ifstream s("readAFile.cpp");
    if (s) std::copy(std::istreambuf_iterator<char>(s.rdbuf()), std::istreambuf_iterator<char>(), std::ostreambuf_iterator<char>(std::cout.rdbuf()));
    else std::cout << "Error reading file";
}

(Note that while yes, one of the lines is fairly long, it is clearly one statement, with one function call. There's no cheating to reduce my LOC count)

7 lines, including the final } on a separate line. Which would put C++ on par with the short ruby version from the original post, and quite a bit shorter than the posted C# version. But not quite as compact as the Python version, of course.

So did I just prove that programmer productivity in C++ is higher than in C# or Ruby? ;)

(This version is slightly different in that it only checks at the beginning, whether the file stream is valid. If the file becomes unreadable during reading, the program just skips the rest of the file without posting an error)

Answer 10

Totally the wrong question - or at least the assumption that that time to create the code is a definition of productivity.

The correct questions - to be posed as a group - would be

1. How long will it take to write the code?
2. How likely is it to produce bugs, and how hard will they be to find and fix?
3. How long will it take me, or a.n.other to grok and amend the code in two years time?
4. How likely is the amendment to produce bugs, and how hard will it be to find and fix them?

Points 2, 3 and 4 are at least as important as 1, and in fact 3 and 4 are probably more so as groking and amending old code often requires more time than the original write.

The number of lines of code it requires to write abstract program X is really pretty meaningless as a measure of real productivity.

Answer 11

I tend to agree that the programming language has less influence on productivity than the comfort of the individual with the tools at hand. If you are really comfortable with the platform (language+libraries+tools), then you are going to be productive. The interesting thing that a few people have noticed is that "productivity" is less important than the quality of the product in the end.

There is quite a lot of "hard research" about productivity gains purportedly based on programming language. I believe (and this is not a researched opinion) that most programming language pundits who claim a particular language increases productivity are probably observing the effect of choosing the right toolkit for the problem at hand. If your job is generating ad hoc/single-run reports for business analysts from a database, then C++ or Java is probably a very bad choice - the output of a command-line SQL tool piped through Perl is going to let you produce reports very quickly.

FWIW, I'd look for research or at any documented proof that choosing the appropriate framework/library and tools followed by educating the engineering staff on how to best use the toolkit produces not only gains in productivity by an increase in product quality as well. Look bake in history a few years when Java was touted over C++ for garbage collected or reference-based memory management - the common outcry was "no more NULL pointers" or "it's impossible to leak memory". That was in the mid nineties. Consider the effect of using boost::shared_ptr and other RAII techniques religiously in C++... no more memory leaks and the same behavior with respect to NULL pointers.

I'm really worried about the effect of switching languages and platforms every five years instead of really learning how to use what we already have correctly. After spending a few years really learning C++ and looking at what frameworks are available, I feel that other languages really have very little to offer over this supposedly dying language. Yes, I probably could have spent the same amount of time retraining myself to use a separate language and environment but it would be hard to convince me that I would be any more productive or produce higher-quality software.

Has anyone really seen any evidence that software has become more reliable as we jump from one programming language to the other. By the time that we start really seeing what we can do in a language, it's time to start over and learn how to replace 'foo' with 'bar' in a string again in another language. From my point of view, the most reliable "real-life" software to date has been written in C and C++... consider Apache WWW Server, ISC Bind, MySQL,BSD-derived OS's (FreeBSD in particular). If we are improving the software engineering landscape so much, then why can't we actually produce software that doesn't crash?

Answer 12

The lines of code studies always assume that you are writing the entire app from scratch.
So Java is more productive than Fortran, but what if you have to reimplmement the NAG libraries for yourself. C# is better than C++, except I have to reinvent openscenegraph.

The choice of language is driven by the platform, framework and libraries available.

Answer 13

Programmer productivity should be measured doing what 80% of the effort is spent on, maintenance programming.

So ask a differnt question.