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.

Community
  • 1
Kit Sunde
  • 18,636
  • 12
  • 93
  • 127
  • 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 --- ex-moderator kitten 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
  • What's up with all these [tag:tags]? – Mateen Ulhaq Apr 17 '11 at 06:32
  • 3
    BTW, I think this question would have better success on Programmers.SE. – Mateen Ulhaq Apr 17 '11 at 06:33
  • @KitSunde: crossposting is a [bad idea](http://meta.stackexchange.com/questions/64068/is-it-possible-to-post-questions-across-a-couple-of-the-sites-because-its-debata/64073#64073). Which version of the question would you like to keep? – Sklivvz Apr 17 '11 at 15:40
  • @Sklivvz - That answer is more dated than employee #5's opinion from the other week on this very site. I linked to over that programmers.SE an admin there said the same thing in the comments. I'm going to bring this issue up on Meta myself to get a clarification. I would keep this one and not the one on programmers.SE, if asked to delete one. – Kit Sunde Apr 17 '11 at 15:53
  • @Sklivvz - I've asked for clarification on the cross-posting rules here: http://meta.stackexchange.com/questions/87739/clarification-regarding-cross-posting-rules – Kit Sunde Apr 17 '11 at 16:13
  • Define "Programming." If you're talking about simple, one-off bits of code then it might be faster for experienced python programmers. If you're talking about large scale enterprise applications then it is definitely not faster at delivering those. Example: "Remote debugging" in Java means you can attach to a JVM that is running on a remote server and debug the app running there. "Remote debugging" using Python means the interpreter spawns a new thread - only on the local machine. As far as I know there is no genuine remote monitoring/debugging for python. – Dan Haynes Dec 19 '14 at 00:43
  • @DanHaynes Obviously I'm not asking about one-off bits of code, where a time difference could be in minutes or hours which is rather uninteresting. The rest of what you said isn't as clear as you make it out to be you can't latch onto a single feature of "remote debugging" as an argument for general efficiency, it's also something Python can do too using PyCharm or various other tools. What I wanted to address is that when someone makes a claim **x** is faster than **y** they do so without hard data, continuing to make unsubstantiated anecdotal or experienced based claims isn't helpful. – Kit Sunde Dec 19 '14 at 06:42
  • @KitSunde I thought the efficiency of remote debugging was self evident. I don't think it's "anecdotal" because there of formal standards like JSR45 Debugging Support for Other Languages and JSR160 Java Management Extensions (JMX) Remote API. Those are evidence of value. You mentioned "saving development time." and I can't think of anything that saves more development time than simple/easy to use monitoring and debugging in situ, however I work on enterprise level multi-tenant, multi-version SaaS systems, not one-off websites, so my definition of efficiency is different than most. – Dan Haynes Dec 20 '14 at 17:15
  • @DanHaynes You're missing the point of what I said, and neither me nor the site is interested in non-empirical answers or comments. – Kit Sunde Dec 21 '14 at 10:56

1 Answers1

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.

Community
  • 1
Konrad Rudolph
  • 12,427
  • 3
  • 56
  • 84
  • 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
  • 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 '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
  • 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 '11 at 00:54
  • @Carson, feel free to check types yourself if it's that important to you: `>>> type("ab") == list False >>> type(["a","b"]) == list True` – Cees Timmerman Nov 19 '12 at 14:29
  • Type checking can indeed catch some errors. But it also makes it hard to do certain things, and require you to often create more code to handle different types, or just cast thing to untyped pointers etc, which causes it's own set of problem. Programmers often believe that the lack of type checking will cause problems, and it feels a bit like jumping off a cliff in the beginning, but the fact is that it doesn't cause much problems, and avoids many others. The main drawback is not programming speed, but execution speed. ;-) – Lennart Regebro Jun 12 '13 at 20:31
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/9265/discussion-between-konrad-rudolph-and-lennart-regebro) – Konrad Rudolph Jun 17 '13 at 10:45