20

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.

Improve this question
13
  • 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, 2011 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 --- ex-moderator kitten
    Apr 16, 2011 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, 2011 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, 2011 at 21:51
  • 3
    BTW, I think this question would have better success on Programmers.SE.
    – Mateen Ulhaq
    Apr 17, 2011 at 6:33

1 Answer 1

Reset to default
14

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.

Improve this answer
8
  • 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, 2011 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, 2011 at 18:54
  • 2
    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, 2011 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, 2011 at 19:28
  • 3
    @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, 2011 at 0:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .