There's a widespread belief among that the more dynamic and loosely typed the language, the more productive the programmer will be in it. Guido van Rossum wrote about programming productivity using python in 1998 and searching around the web I still see people referencing this exact claim:

Syntactically, Python code looks like executable pseudo code. Program development using Python is 5-10 times faster than using C/C++, and 3-5 times faster than using Java. In many cases, a prototype of an application can be written in Python without writing any C/C++/Java code. Often, the prototype is sufficiently functional and performs well enough to be delivered as the final product, saving considerable development time. Other times, the prototype can be translated in part or in whole to C++ or Java -- Python's object-oriented nature makes the translation a straightforward process.

Has this issue been properly scientifically evaluated? If not for then perhaps for sibling scripting languages like , or ?

I'm not looking for rationalizations, analogies, or explanations why it could potentially be hard to answer, unless it's the opinion of researchers or experts that has taken the time to look into the issue.

I initially asked this question over at skeptics.SE, and someone suggested I should ask it here too.

  • 25
    Well, since you've restricted the set of possible answers, I just dare a comment by asking another question which should be answered first (imho): Is there a reliable and estabilished metrics for measuring the "productivity of a programmer"? Apr 17, 2011 at 8:49
  • 1
    @Paul Michalik - I would assume that any research paper that looked at productivity would have a definition included (otherwise it would be really hard to measure). So if someone referenced research it would be helpful if they included the definition in the answer. There is probably (I'm guessing) several different perfectly acceptable ways to measure productivity, perhaps "Time it takes to pass a number of unittests" would be one of them.
    – Kit Sunde
    Apr 17, 2011 at 8:53
  • 1
    @Paul Michalik - Sure but how many of the statements you read in books, blogs, talks and articles from programmers are actually tested empirically? I'm sure there are better or worse ways of measuring productivity. For instance. "Coffee consumption/time" would probably be a worse one than even the classical "Lines of code/time". I would hold back judgement on specific productivity claims we've seen one and can argue the merits based on that. Productivity claims aren't just plain wrong either, I'm sure "lines of code/time" measure something when people aren't trying to destroy the metric.
    – Kit Sunde
    Apr 17, 2011 at 9:23
  • 1
    You might be interested in this article: citeseerx.ist.psu.edu/viewdoc/… Apr 17, 2011 at 9:56
  • 1
    @ChrisF - Are you saying that this quesiton isn't applicable to Programmers.SE? It certainly is to skeptics, and it seemed to fit here too. I was under the impression that you shouldn't until I read a recent comment by Robert Cartaino on this question: skeptics.stackexchange.com/q/1963/631 which essentially says that it's perfectly okay if it's of interest to both communities, and I only did it after being prompted by another user to do so. Considering that the question is getting upvotes, it would seem it's an interest to this community as well.
    – Kit Sunde
    Apr 17, 2011 at 10:57

5 Answers 5


Ousterhout's article1 about scripting languages suggests that the higher level the programming takes place, the more productive the programmer is. If we take that, as Boehm says2, the number of lines a programmer can write in a given time is constant and not dependent on the language or its type (low level, system programming, scripting), one can easily believe the claim. The resulting instructions-per-source-code-line -ratio can be an order of magnitude (or several) better with scripting languages than with system programming languages.

As scripting languages heavily rely on ready-made utilities for common tasks (e.g. data structures, string manipulation), their main use usually is to enhance productivity with the cost of slower running speed by providing a syntax that's easy to learn and efficient to upkeep programs with. One doesn't resort to a scripting language when top execution speed is needed.

[1]: J. K. Ousterhout, Scripting: Higher Level Programming for the 21 Century, Computer (IEEE), 1998
[2]: B. Boehm, Software Engineering Economics, Prentice Hall, 1981

  • 9
    While this is a good answer, don't forget that modern non-scripting languages also tend to come packed with ready-made utilities that make development fast. C# comes to mind. Anyone who feels Python comes with more pre-canned utilities than C# simply happens to know Python better than C#. In reality they both have a vast and comparable range of "built-in" utilities. Apr 17, 2011 at 13:10
  • 1
    @romkyns, for any non-trivial project you need to write a lot of code. Even if you have plenty of Lego bricks the Bionicles do not magically come together.
    – user1249
    Apr 17, 2011 at 15:43
  • 3
    @Thor but it does really rather help to have those Lego bricks upfront, instead of having to build an oil drill, a plastic factory and a lego block extruder first. Apr 17, 2011 at 17:59
  • 2
    both c++ and Java have generic containers, and c++11 has such a full standard lib for sort algorithms and iterators etc. I'm not convinced that someone programming python would be at a substantial advantage. Furthermore I for one spend most of my programming time working out what it is I need to do, not typing. So I think just counting the amount of lines it takes to do a thing is not a clear indicator of how fast a programmer you would be in that language.
    – Sam Redway
    Aug 5, 2015 at 17:41
  • @SamRedway Very good point: different people code for different things, and thus in different ways. However I wanted to add that in my opinion the advantages of Python towards C++ and Java are plenty of syntax sugars. Take three common ones: auto-typing (even don't need to use auto), generic-by-default (don't need to wrap every function with template<...>), list comprehension. Syntax sugars are the second advantage, and the first advantage I think is a fast-responding community - see how many PEPs are made. Python is growing quickly, but C++ etc. are growing in years. (C++11, 17) Aug 9, 2021 at 14:21

If you measure productivity as "time to write a specific simple program" then it depends so much more on programmer experience and quick mind than the language that you are really evaluating the programmer, not the language.

I believe timed code contests indicate that the language doesn't really matter for those kinds of tasks. There is no one language that wins such challenges easier than others (at least not if you allow for the relative popularity of languages).

If you measure performance as "the effectiveness of the best program" written in a given language, then it's even less language-dependent. See for example the results of the Galcon AI contest. The winner is written in Lisp. The next Lisp entry, however, is ranked #280. What does this tell us about the language's suitability for writing great AI efficiently? In my opinion, nothing. It just tells us that "bocsimacko" came up with and implemented the most effective algorithms. For the record, time was not a major factor in this contest - people had more than two months to develop their code.

Lastly, if you measure performance as "long-term cost of maintaining a project" then I think you're onto something. Especially if you hire only the best people for the job, and count cost in man-hours rather than dollars. I have a strong opinion on which languages are best for this, but having no hard evidence to link you to I'll leave this opinion out. Perhaps someone else has links for this type of performance.

  • 8
    "you are really evaluating the programmer, not the language" - Not if this is actually done scientifically. Take 100 programmers. Select a general project such as "Write a calendar app with these specific requirements". The requirements a tied to automated unit testing. 50 programmers write the app in C++, 50 in Python, selected at random so the quality developers are evenly dispursed. The results would be a score combining the average time to completion with the number of unit tests passed. Compare the average of the Python results with the average of the C++ result and...SCIENCE! May 4, 2011 at 21:35
  • 3
    @Prof Maybe if you get a thousand of each... but still, how do you control for the fact that only people with a certain mindset and a certain level of ability will know C++? May 4, 2011 at 21:44
  • you could make your sample only pull from people who can pass a proficiency test in C++ and Python. A lot of my old professors were doing very similar studies. Also you make a couple of assumptions that others have discussed here: programmers.stackexchange.com/q/73715/3792 May 5, 2011 at 14:27

http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf is one of the few studies which I am aware of that did an actual direct comparison between productivity in various languages. It is old, but worth reading if you find the topic interesting. The comparison has a number of major shortcomings which the article is very honest about.

The overall result is that low level languages (eg C, C++) take longer to write, can take much less memory, and can run much faster. But with very high variability. High level scripting languages tend to take half as long to write and have less variability in approach. To an initially surprising degree, there does tend to be an obvious way to do something in a scripting language.

Note that all performance numbers for Java should be taken with a major grain of salt - the paper was produced in the 90s before people had a lot of experience with Java, and before the JVM was well optimized. Both factors should have significant impact.


To put it generally, writing a program in Python will usually be faster than writing the same program in C, C++, Java.

It is also likely to run slower.

There are, of course, particular applications for which other languages may be quicker because certain tasked involved are 'more natively' supported.

While I am not aware of any studies to confirm this increase in speed/productivity (as one commenter mentioned, this can be tough to measure precisely), there has been direct research into the expressiveness of language.

I think there is some merit to a correlation between language expressiveness and programming speed. Just picture a simple iteration pattern and how a Pythonic for-loop or list comprehension can be more succinct. Not only can it be immediately typed faster, but it also eliminates concerns of off-by-one errors, indices out of bounds, and other such problem that can significantly slow the coding process.

This shows a table an estimate for expressiveness ratios of languages. While it should be taken with a grain of salt, the footnotes it mentions are very worthwhile.



Last time I used Java (a while ago admittedly) it took a screen full of code to open and write to a file. Compare that to a couple of lines in Python or Perl, and you can guess which one is faster.

Obviously languages all have their own strengths and weaknesses, but for most tasks Python will be faster to write.

  • 6
    "it took a screen full of code to open and write to a file": Put this into a utility class with two methods write() and read() and in the rest of your Java project file access will be as concise as in Python. I think your example is a bit too restricted to compare Python and Java (even though I agree that Java tends to be more verbose).
    – Giorgio
    Dec 31, 2012 at 14:13
  • Sure, but Python, Perl and higher languages have generally thought about that stuff in advance, and so you don't need to write the utility classes (or not as many of them). Using a utility class still takes time, and is a principle of reusable code that applies top both Java and Python depending on what you are actually doing. Sep 20, 2013 at 10:42
  • This assumes that Java needs 50 - 60 lines of code just to open and write a file. This is simply not correct.
    – h22
    Jan 10, 2018 at 15:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.