Take the 2-minute tour ×
Skeptics Stack Exchange is a question and answer site for scientific skepticism. It's 100% free, no registration required.

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've also asked the question over on programmers.SE after a suggestion by muntoo.

share|improve this question
1  
Just compare the length of equivalent programs - in perl and python many programs (usually short to medium) are significantly shorter and simpler. for large project's the differences are smaller, and sometimes even in favor of "classic" programming languages. –  Ophir Yoktan Apr 16 '11 at 20:29
    
Essentially every programmer has had the experience of a dynamic language being loads faster when the problem matched the tool. So one part of the equation is: what problems are in front of you? I personally have had good luck with python despite writing c-in-python style code still. –  dmckee Apr 16 '11 at 21:03
5  
There are many factors that you must take into account when considering development time: Python, for example, has a much larger standard library than C/C++ does, so it comes ready with network support, serialization support and a lot of fancy stuff, all only a single "import" away. –  Lagerbaer Apr 16 '11 at 21:38
    
I considered adding a list of common arguments and rationalizations to this question when I wrote it, to stop them happening in comments (but decide not to). I'm well aware of all kinds of arguments and issues coming from every angle (as I'm sure all of you do), but without any supporting evidence it's just noise in the context we are in right now. I would prefer it if we could avoid the traditional (and seemingly obligatory) pessimism to approaching this question, unless you've taken time to look at the research and are referencing how hard the researchers think this issue is. –  Kit Sunde Apr 16 '11 at 21:51
3  
BTW, I think this question would have better success on Programmers.SE. –  muntoo Apr 17 '11 at 6:33

1 Answer 1

I know of no research corroborating the claim that loosely typed languages are more productive. In fact, I believe the opposite should be true (since stricter typing means that the language prevents the programmer from making hard to find errors, thus saving a lot of debugging time).

However, there have been (a few) studies measuring the respective productivity of languages such as Java, Python and C++. A detailed discussion can be found on Stack Overflow, “Are there statistical studies that indicates that Python is ‘more productive’?”.

Some work here has been done by Lutz Prechelt in An Empirical Comparison of Seven Programming Languages.

Doing such studies is very problematic since a lot of factors influence productivity and it’s not clear how to eliminate them systematically. The studies are also very difficult to replicate, not least of all because it takes a lot of effort to lead such a study and nobody is willing to pay for it. Finally, there is no good agreed-on measure for productivity in programming languages.

share|improve this answer
2  
Good answer, one quibble: prevents the programmer from making hard to find errors - This is a can of worms. Suffice it to say that (i) the ugliest bugs arise from design errors and programmer misunderstanding, and type systems are no use with these, (ii) sophisticated type systems can do a lot of shallower correctness checking, and (iii) good programming practice can make up for deficiencies in the type system, bad programming practice can short-circuit just about any safety offered by the typing system. –  Charles Stewart Apr 18 '11 at 18:50
1  
@Charles About (i), this is of course true but weak typing doesn’t improve that. So the net bonus is still with strict typing. (ii) I don’t understand. (iii) is of course true. –  Konrad Rudolph Apr 18 '11 at 18:54
1  
Python is a good glue language, but for large systems it really gets confusing. Take waf, the build tool, for instance. It'll frequently mess up and only give you a vague callstack because the loose typing system has allowed an incorrectly-typed variable to propagate through the system. –  Chris Dennett Apr 18 '11 at 19:20
    
I'm not arguing that the point is wrong exactly; (ii) is the reason why the potential benefit from typing can be very great indeed, since a large number of static analyses can be modelled in the type system and automated with type inference. The point is that the benefits of typing discipline are complex and inseparable from other issues about PLs and programming practice, rather in the manner of your remark about study design. Not to mention the fact that type systems can introduce problems. –  Charles Stewart Apr 18 '11 at 19:28
2  
@Chris that's a big caveat of duck typing that bites me from time to time: the error can occur miles away from the problem. One example that gets me is giving a string to a function, when I should have given it a list containing that string (eventually I wonder why later code is tossing single characters around) –  Carson Myers May 20 '11 at 0:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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