Programming language productivity

[Connelly Barnes]

Hi Python folks,

I created a summary PDF of two studies on programming language productivity:

http://barnesc.blogspot.com/2006/05/programming-language-productivity.html

One notes that Python and Perl are the two best languages by the "number of hours to
solve problem" metric.

I ran into these studies when I was learning Common Lisp, and Googled "lisp
productivity." The 2nd hit described the frustrations of Brandon Corfman in trying
to reproduce Norvig's Lisp solution to a problem. This led me to Norvig's article,
which cited the two given studies. There may be entire areas of academia
devoted to studying the "productivity problem;" if so, then I am not familiar with
the research in that area, so please let me know where I should look for better/more
recent research!

- Connelly Barnes


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

 

[John Bokma]

http://barnesc.blogspot.com/2006/05/programming-language-productivity.h
tml

C: 3 hours to write the program, 5 hours to track down the memory leaks
Java: 4 hours to write the program, 6 hours to get all the exception
handling right
C++ 5 hours to write the program after reading Stroustrup for 6 hours

Just kidding, of course.

Also note that Python programmers write more lines/hour which they need to
finish in the same time as Perl programmers :-D.

 

[Harry George]

[snip]

Once you get involved in larger projects, the dynamic nature of the
programming tool becomes much more important. I mean by this, the
ability to stop running code, modify or add to it and continue without
having to re-establish the state of the program. This may sound trivial
to many, but in major applications setting up the state again can take
a considerable processing time. Such feature should be available from
within the debugging tools.

In fact, languages like Smalltalk, Lisp and even VB offer this
possibility.
Ruby coming up strongly these days also has this dynamic reload
capability.
To sum up, I like Python very much but I don't understand how come this
basic flaw has not been taken care of. It is sufficient to search for
"reload" to see how many people have struggled with it over the years.
I hate the idea of having to take up Ruby to really find out how it
could serve me better in this most critical productivity area.

What is "major project"?

We have 50 people working on a project, over 5 years, in Python. Much
of the regresison test can be done by rebuilding context in RAM (no
need to persist). That is immediate (whole test suite runs in a few
seconds). Sometimes we have to reestablish context by clearing the
database and then reloading objects from test_input XML files. That
is slow (perhaps an over night job). I've yet to experience a context
where language features are the rate limiting step.

On the other hand, I have definitely experienced language as a rate
limiting factor in a) peer code reviews, b) debugging, c) ramping up
new team members. Python wins those battles everytime.

 

[malv]

C: 3 hours to write the program, 5 hours to track down the memory leaks
Java: 4 hours to write the program, 6 hours to get all the exception
handling right
C++ 5 hours to write the program after reading Stroustrup for 6 hours

Just kidding, of course.

Also note that Python programmers write more lines/hour which they need to
finish in the same time as Perl programmers :-D.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

I am not shure whether your criterion is very valid. OK if you have to
write only one compact piece of code like in your example. Sometimes I
think that most python users fall within this category.

Once you get involved in larger projects, the dynamic nature of the
programming tool becomes much more important. I mean by this, the
ability to stop running code, modify or add to it and continue without
having to re-establish the state of the program. This may sound trivial
to many, but in major applications setting up the state again can take
a considerable processing time. Such feature should be available from
within the debugging tools.

In fact, languages like Smalltalk, Lisp and even VB offer this
possibility.
Ruby coming up strongly these days also has this dynamic reload
capability.
To sum up, I like Python very much but I don't understand how come this
basic flaw has not been taken care of. It is sufficient to search for
"reload" to see how many people have struggled with it over the years.
I hate the idea of having to take up Ruby to really find out how it
could serve me better in this most critical productivity area.

 

[Jack Diederich]

Once you get involved in larger projects, the dynamic nature of the
programming tool becomes much more important. I mean by this, the
ability to stop running code, modify or add to it and continue without
having to re-establish the state of the program. This may sound trivial
to many, but in major applications setting up the state again can take
a considerable processing time. Such feature should be available from
within the debugging tools.

In fact, languages like Smalltalk, Lisp and even VB offer this
possibility.
Ruby coming up strongly these days also has this dynamic reload
capability.
To sum up, I like Python very much but I don't understand how come this
basic flaw has not been taken care of. It is sufficient to search for
"reload" to see how many people have struggled with it over the years.
I hate the idea of having to take up Ruby to really find out how it
could serve me better in this most critical productivity area.

Please stop saying 'Python' should support this like 'Ruby' because
'Ruby' doesn't -- Rails, the application, does. Rails can do it most
of the time because it knows the particulars about Rails objects. If
you are messing with the internals of Rails I'm sure an call to
'Dispatcher.restart_application'[1] has a good chance of dying.

Complain to the developers of python _applications_ if their app
doesn't have this feature. As I said last time you b*tched about it,
there can't be a standard magic reload that works on everything.
Application developers can implement something that works for their
specific application because they know the internals.

If you are going to complain please at least post some context
about what you think should happen and some links to how other folks
have implemented it. Asserting python should do 'Reload and Go'
isn't very helpful.

-Jack

[1] I googled up a reference to it here
<http://www.unpossible.com/2006/04/20/time-saver-rails-console-reset/#comments>

 

[Peter Maas]

Also note that Python programmers write more lines/hour which they need to
finish in the same time as Perl programmers :-D.

You probably want to say that a Python program tends to have more lines than
an equivalent Perl program.

I think that a LOC comparison between a language that enforces line breaks
and another language that enables putting an lots of code in one line doesn't
make much sense. I wonder why comparisons aren't made in terms of word count.
Word count would include literals, constants, variables, keywords, operators,
bracket- and block delimiter pairs. Python indent/unindent would of course
also count as block delimiters. I think this would be a more precise measure
for software size.

Peter Maas, Aachen.

 

[Edward Elliott]

I think that a LOC comparison between a language that enforces line breaks
and another language that enables putting an lots of code in one line
doesn't make much sense. I wonder why comparisons aren't made in terms of
word count. Word count would include literals, constants, variables,
keywords, operators, bracket- and block delimiter pairs. Python
indent/unindent would of course also count as block delimiters. I think
this would be a more precise measure for software size.

I don't disagree, but "word" counts aren't so simple, either to define or to
implement. What counts as a word? Parser tokens? That counts a.b (or
a::b, or a->b, depending on language) as 3 words. Block delimiters? After
a month, you don't even notice them in properly formatted code, which is
why python doesn't have them in the first place. Operators? Then e.g.
a = b + c + d + e counts more than a = add (b, c, d, e). The complexity of
expressions seems determined by the numbers of operands; using operators as
well arguably overcounts.

Regardless of the above choices, you still need a parser (or at least a
lexer) to count anything. Whitespace separation won't cut it - what
happens with 'for (i=0;i<5;i++)' or 's = "foo bar baz"'? If you toss out
operators, you could almost get away with regular expressions for counting
the identifiers, keywords, and literals. But there's still the problem of
overcounting string literals.

Line counts are simple to compute and it's easier to agree on which lines to
count. Thus their popularity.

 

[John Bokma]

You probably want to say that a Python program tends to have more
lines than an equivalent Perl program.

No, I was just making a joke based on the graphs given on the site
mentioned earlier.

I think that a LOC comparison between a language that enforces line
breaks and another language that enables putting an lots of code in
one line doesn't make much sense. I wonder why comparisons aren't made
in terms of word count. Word count would include literals, constants,
variables, keywords, operators, bracket- and block delimiter pairs.

No idea, I consider comparisons like this quite meaningless when people
attempt to use them as a kind of quality measurement.