Re: Programming language productivity

2006-05-21 Thread Peter Maas
John Bokma wrote:
 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Programming language productivity

2006-05-21 Thread Edward Elliott
Peter Maas wrote:

 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;i5;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.

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Programming language productivity

2006-05-21 Thread John Bokma
Peter Maas [EMAIL PROTECTED] wrote:

 John Bokma wrote:
 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.

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.


-- 
John   MexIT: http://johnbokma.com/mexit/
   personal page:   http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Programming language productivity

2006-05-19 Thread malv
John Bokma wrote:
 Connelly Barnes [EMAIL PROTECTED] wrote:

  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.

 --
 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Programming language productivity

2006-05-19 Thread Harry George
malv [EMAIL PROTECTED] writes:

[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.

-- 
Harry George
PLM Engineering Architecture
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Programming language productivity

2006-05-19 Thread Jack Diederich
On Fri, May 19, 2006 at 02:21:39AM -0700, malv wrote:
 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Programming language productivity

2006-05-18 Thread 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 
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Programming language productivity

2006-05-18 Thread John Bokma
Connelly Barnes [EMAIL PROTECTED] wrote:

 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.

-- 
John   MexIT: http://johnbokma.com/mexit/
   personal page:   http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
-- 
http://mail.python.org/mailman/listinfo/python-list