Python Productivity Gain?

[Lothar Scholz]

Re: Python Productivity Gain?

Peter Hansen <peter@engcorp. com> wrote in message news:<4030D3E5. BE372ACB@engcor p.com>...
[color=blue]
> As for "most programmers are coming from Windows background" I suspect
> that too is very debatable.[/color]

Right. I don't know any german university where programming (at least
in the computer science courses) is teached on windows systems.

[Lothar Scholz]

Re: Python Productivity Gain?

Peter Hansen <peter@engcorp. com> wrote in message news:<4030D457. D193F14C@engcor p.com>...[color=blue]
> Matthias wrote:[color=green]
> >
> > This study reports a programmer productivity gain of about 2 for all
> > the scripting languages over C, C++, and Java. It is a pity that not
> > more attempts to gain /unbiased/ information on software productivity
> > are undertaken.[/color]
>
> I agree. Unfortunately, it appears, the cost of doing that is just too
> high. Several times I've wanted to do a study in my company to measure
> the claimed productivity improvements of Python (and of other things) but
> in the end without funding it's not likely to happen, or to be credible.
>[/color]

A good study of this would cost around 750000 US$ and take at least
one year with 2 or 3 persons per team. It's not a problem for IBM or
SUN to pay for it.
But they live on selling consulting hours. Why should they be
interested in a study of who to increase programmer productivity ?

[GerritM]

Re: Python Productivity Gain?

"Peter Hansen" <peter@engcorp. com> schreef in bericht
news:40323814.3 129EA4B@engcorp .com...[color=blue]
> My background is (roughly in order) APL, FORTRAN, BASIC, Assembly, C,
> university :-), Pascal, C++, Object Pascal, Java, LabVIEW, and Python
> (with a dozen others I forget) and I'm telling you Python is a really
> great language. I've also dumped my previously favourite languages
> (to wit, BASIC, C, C++, Delphi, and Java) to focus on Python.
>
> Now all you need are 19 others and we'll have a significant data point.
> (Signifying what? That's what I want to know. ;-)
>[/color]
Fortran, Basic, Assembly many times, Pascal, C, Objective-C, Object Pascal,
C++, Java and Python.
Yes Python beats the rest wrt productivity for most of my applications :-)

Now do we need 18 more for a SIGNIFICANT data point?

regards Gerrit
--

https://www.extra.research.philips.com/natlab/sysarch/

[Peter Hansen]

Re: Python Productivity Gain?

Lothar Scholz wrote:[color=blue]
>
> A good study of this would cost around 750000 US$ and take at least
> one year with 2 or 3 persons per team. It's not a problem for IBM or
> SUN to pay for it.
> But they live on selling consulting hours. Why should they be
> interested in a study of who to increase programmer productivity ?[/color]

They do much more than consult, as they sell/lease substantial amounts of
software and hardware, as well as working on many very large fixed-price
projects. For all of those, minimizing their own costs would be very
important to achieving a good margin and profitability.

Besides, they spend enormously more than US$750,000 each year on much
less important studies. Overall, they spend almost 7000 times that much
each year on R&D (according to their 2000 annual report), which means that
spending US$750,000 on a study like this would be very roughly as if you
or I were to spend $10.

For my own company, the study would be quite costly. For a much larger
company it's a drop in the bucket, and might well contribute to them
gaining a competitive advantage.

The likelihood is that they (IBM and others) already fund such studies
internally, but don't make the results public.

Possibly equally likely, however, is that any such studies are seriously
flawed and support the political position of whomever funds the project,
or whomever leads it.

Which gets us right back to square one...

-Peter

[Paul Prescod]

Re: Python Productivity Gain?

kbass wrote:
[color=blue]
> In different articles that I have read, persons have constantly eluded to
> the productivity gains of Python. One person stated that Python's
> productivity gain was 5 to 10 times over Java in some in some cases. The
> strange thing that I have noticed is that there were no examples of this
> productivity gain (i.e., projects, programs, etc.,...). Can someone give me
> some real life examples of productivity gains using Python as opposed other
> programming languages.[/color]

The problem is always: how do you measure/judge this?

Are you going to get the SAME PROGRAMMERS to solve the same problem
twice? If so, the second language will have a big advantage. Are you
going to get different programmers? How do you know they are the same skill?

Also: productivity for what? If your Java code is a little bit of glue
around some pre-existing EJBs then it may have an advantage. If you are
using Python and Pyrex to wrap C code, then Python will certainly have
an advantage.

Most Python programmers are speaking about their personal productivity
gain measured based on "feel". It is possible to do a more formal study
(dozens of programmers given a variety of tasks) but it would be quite
expensive. What unbiased source is going to pay for it.

Paul Prescod

[Dave Brueck]

Re: Python Productivity Gain?

kbass wrote:[color=blue]
> In different articles that I have read, persons have constantly eluded to
> the productivity gains of Python. One person stated that Python's
> productivity gain was 5 to 10 times over Java in some in some cases. The
> strange thing that I have noticed is that there were no examples of this
> productivity gain (i.e., projects, programs, etc.,...).[/color]

If you're interested in funding a study, I'm sure you could get someone to do a
truer test. Short of that, the evidence is mostly anectdotal because it's rare
"in the real world" to rewrite one non-trivial application in a different
language just for the heck of it. There are almost always changes in program
architecture or feature set so that it's tough to do an apples-to-apples
comparison.

That said,

http://tinyurl.com/39jsh

-Dave

[Dave Brueck]

Re: Python Productivity Gain?

William wrote:[color=blue]
> kbass <kbass@midsouth .rr.com> wrote:[color=green]
> > In different articles that I have read, persons have constantly eluded to
> > the productivity gains of Python. One person stated that Python's
> > productivity gain was 5 to 10 times over Java in some in some cases. The
> > strange thing that I have noticed is that there were no examples of this
> > productivity gain (i.e., projects, programs, etc.,...). Can someone give[/color][/color]
me[color=blue][color=green]
> > some real life examples of productivity gains using Python as opposed other
> > programming languages.
> >
> > From my our personal experience, I have been programming with Python for
> > about 6 months (but I have been programming in other languages for over 10
> > years) and I have noticed that the more I had gotten use to programming in
> > Python, the more my programming speed has increased. But ... this is true
> > with any language that you program in as long as you are learning the
> > methodologies and concepts of the programming language. Your thoughts.[/color]
>
> It used to be that Python programs were shorter, faster, readable,
> writable, and simply better. But, this was during the days when most
> programmers had Unix background. Nowdays, most of the programmers are
> coming from Windows background, and Python programs have become as
> verbose and unreadable as Visual Basic or Perl.[/color]

I have a tough time taking this comment seriously - didja forget some smilies?
If not, you're basing this opinion on ______?

Is there any evidence that implies that for the same tasks the programs are now
longer, slower, less readable, less writeable, or worse? (or that any slip has
been caused by more Windows programmers?)
[color=blue]
> Ruby has not been corrupted as such. It make complicated thing less
> complicated. But, it still make simply thing not as simple as Python.[/color]

???

[Paul Rubin]

Re: Python Productivity Gain?

Paul Prescod <paul@prescod.n et> writes:[color=blue]
> Are you going to get the SAME PROGRAMMERS to solve the same problem
> twice? If so, the second language will have a big advantage. Are you
> going to get different programmers? How do you know they are the same
> skill?[/color]

Maybe it doesn't matter. If you hire your programmers by running an
ad in the paper, and advertising "Python programmers wanted" gets you
better programmers than advertising "VB programmers wanted", maybe
that by itself is good enough reason to do your project in Python,
irrespective of whether Python is objectively better than VB.

[jmdeschamps]

Re: Python Productivity Gain?

Peter Hansen <peter@engcorp. com> wrote in message news:<40323814. 3129EA4B@engcor p.com>...[color=blue]
> Harry George wrote in a thought-provoking post:[color=green]
> >
> > Of course, even in the natural history phase pioneers and advance
> > scouts are capable of detecting an easier pass through the mountains
> > of comlexity. If 20 people from varied background, each of whom has
> > worked in several languages, tell me that Python is a really great
> > language, then I'll take that as a significant data point. Especially
> > if they are dumping their previously favorite languages (as varied as
> > COBOL, Perl, Java, C++, VB, Modula-3, Lisp, Prolog) to focus on
> > Python.[/color]
>
> My background is (roughly in order) APL, FORTRAN, BASIC, Assembly, C,
> university :-), Pascal, C++, Object Pascal, Java, LabVIEW, and Python
> (with a dozen others I forget) and I'm telling you Python is a really
> great language. I've also dumped my previously favourite languages
> (to wit, BASIC, C, C++, Delphi, and Java) to focus on Python.
>
> Now all you need are 19 others and we'll have a significant data point.
> (Signifying what? That's what I want to know. ;-)
>
> -Peter[/color]

Well here goes! I started in Prolog (coming from formal logic it was a
breeze), done Pascal, some Forth (not much), a little Smalltalk, C,
C++, Java, Javascript, HyperTalk/Supertalk,(+ otherTalks ) - VB, VBA,
AppleScript, started doing Perl (for CGI) then read about doing this
stuff in Python instead! Ported my research work from Java to Python
and never looked back (but sure you can always use another language:-)
Wow, never had so much fun since Working with Cratfman on NeXT! Thanks
GvR!

Jean-Marc
ps That's 2, 18 to go!

[Anton Vredegoor]

Re: Python Productivity Gain?

"GerritM" <gmuller@worldo nline.nl> wrote:
[color=blue]
>Fortran, Basic, Assembly many times, Pascal, C, Objective-C, Object Pascal,
>C++, Java and Python.
>Yes Python beats the rest wrt productivity for most of my applications :-)
>
>Now do we need 18 more for a SIGNIFICANT data point?[/color]

Fortran, C, Lisp, Elan, Gfabasic, Pure C, Borland Pascal, Borland C,
Borland C++, Visual Basic, Delphi, Python

Python is the first language out of this list for me that I can forget
about while using it, so that I can concentrate on the algorithmic
aspects of the problem.

My next language will probably one that suggests a better algorithm
after me typing in some pseudo code. Maybe using some interface to
comp.lang.xxxxx x for the interpreter?

17 to go.

Anton

[Cameron Laird]

Re: Python Productivity Gain?

In article <3064b51d.04021 81326.1b046f29@ posting.google. com>,
<beliavsky@aol. com> wrote:

[Harry George]

Re: Python Productivity Gain?

corey.coughlin@ attbi.com (Corey Coughlin) writes:
[color=blue]
> It is a difficult problem, but I don't think it's completely
> insurmountable. Take some programmers right out of school, or just a
> general population of people, give them training in language X for a
> fixed period of time, set them up to perform some task, and see how
> long it takes them. Sure, some of them will be better programmers
> than others, but with a large enough sample population you should be
> able to draw some conclusions on the average, if there is an effect to
> be measured. And yes, the bigger the population, the better the
> results, so it would be fairly expensive to conduct, but still, you
> could draw conclusions. Getting funding would be tricky, though,
> that's a given.
>
>[/color]

It is common for a ComSci prof or grad student to crank up such a
study, using undergrad and grad students as the subjects. These
subjects can generally be coerced to participate ("it is required for
the course"). For "novice programmer" research, high school students
are often used. These tend to be self-selected, and ar not
representative for the general population.

So it is possible to set up such an experiment, and even to attend to
all the statistical niceties. The problem is that the experimental
model fails to match reality in other ways.

For example, real world teams have usually solved interpersonal
pecking orders and courting rituals before the coding starts. They
have domain knowledge beyond reading a (possibly fake) case study.
They have well-honed development environments, and may have existing
sets of unittests. Their requirements/directions are subject to major
changes in midstream.

These conditions are hard to duplicate in a short term academic
settings. They cannot be solved by larger sample size. That's why I
suggest that "lab research" is not ready for prime time in this field.

Some researchers have gone out in the field to use working teams.
Others retrospectively examine past projects. These have the flavor
of "field research".



[color=blue]
>
>
> Paul Prescod <paul@prescod.n et> wrote in message news:<mailman.8 6.1077050210.31 398.python-list@python.org >...[color=green]
> > kbass wrote:
> >[color=darkred]
> > > In different articles that I have read, persons have constantly eluded to
> > > the productivity gains of Python. One person stated that Python's
> > > productivity gain was 5 to 10 times over Java in some in some cases. The
> > > strange thing that I have noticed is that there were no examples of this
> > > productivity gain (i.e., projects, programs, etc.,...). Can someone give me
> > > some real life examples of productivity gains using Python as opposed other
> > > programming languages.[/color]
> >
> > The problem is always: how do you measure/judge this?
> >
> > Are you going to get the SAME PROGRAMMERS to solve the same problem
> > twice? If so, the second language will have a big advantage. Are you
> > going to get different programmers? How do you know they are the same skill?
> >
> > Also: productivity for what? If your Java code is a little bit of glue
> > around some pre-existing EJBs then it may have an advantage. If you are
> > using Python and Pyrex to wrap C code, then Python will certainly have
> > an advantage.
> >
> > Most Python programmers are speaking about their personal productivity
> > gain measured based on "feel". It is possible to do a more formal study
> > (dozens of programmers given a variety of tasks) but it would be quite
> > expensive. What unbiased source is going to pay for it.
> >
> > Paul Prescod[/color][/color]

--
harry.g.george@ boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: (425) 342-0007

[beliavsky@aol.com]

Re: Python Productivity Gain?

claird@lairds.c om (Cameron Laird) wrote in message news:<1039hhilr s4rb5@corp.supe rnews.com>...
[color=blue]
> These are good points to raise.[/color]

Thanks for your informative reply.
[color=blue]
> Fortran's my first language. I have little opportunity nowadays to
> exercise it, much as I'd like to do so. I'm certainly not as current
> with it as you.[/color]

If you are willing to spend the time to learn it, a subset Fortran 95
language called F is free for Windows, Linux, and other platforms --
see http://www.fortran.com/F . A project to create a full Fortran 95
open-source compiler is well underway and may be completed this year.
[color=blue]
> When I read, "It's also clear from reading the declarations what the
> function is returning ...", I take it that you have in mind such
> distinctions as FLOAT vs. INT. Reasoning about types is a *frequent*
> topic of discussion in comp.lang.pytho n. I'll summarize my experience
> this way: FLOAT vs. INT (and so on) takes little of my day-to-day
> attention. I focus on unit tests and coding which is semantically
> transparent in a more comprehensive way than just type-correctness.
> Therefore, while I acknowledge the advantages you describe for Fortran,
> I categorize them mostly as, "no big deal".[/color]

It's not just float vs. int. Below is a very simple illustration --
code to compute the standard deviation of a set of numbers, in Fortran
95 and Python. In the F95 code, it is clear that
(1) x(:) is a 1-d array of real's that will not be changed inside the
function (note the intent(in))
(2) the function returns a single value (F95 functions can return
arrays and structures, if they are declared as such).
(3) the function has no side-effects because it is declared PURE.

In the python code, all you know is that sd() takes one argument. It
could change that argument or some other global variable. It could
return a scalar that is real, integer, or something else. It could
return a list, a 1-D Numeric array, a 2-D Numeric array etc.

pure function sd(x) result(value)
! compute the sd of a vector
real , intent(in) :: x(:)
real :: value
integer :: n
real :: xmean
n = size(x)
value = 0.0
if (n < 2) return
xmean = sum(x)/n
value = sqrt(sum((x-xmean)**2)/(n-1.0))
end function sd

def sd(x):
""" compute the sd of a vector """
n = size(x)
if (n < 2): return -1
xmean = sum(x)/n
return sqrt(sum((x-xmean)**2)/(n-1.0))

In this case, and for other numerical work, I prefer Fortran 95 to
Python, even ignoring speed advantages and the advantage of an
executable over a script. F95 can look a lot like Python -- no curly
braces or semicolons, and a lack of C/C++ trickery in general.

Of course, Python and other scripting languages were not primarily
designed for numerical work. Numeric Python is powerful and elegant.

Another point. Python advocates often claim it is better than compiled
languages because the code is much shorter. They rebut worries about
the loss of safety by recommending unit testing. In a Fortran 95 or
C++ program, I don't think as many tests need to be written, because
the compiler catches many more things. If you include the amount of
testing code when counting the amount of code needed, I suspect
Python's brevity advantage will partly disappear. Also, I regard unit
tests to check what happens when a Python function is called with
invalid arguments (int instead of float, scalar instead of array) as
low-level, tedious work that I would rather delegate to a compiler.
Scripting advocates claim that their languages are higher level than
compiled languages, but in this case the reverse is true -- the
compiler does more work for you than the interpreter does.

[Dave Brueck]

Re: Python Productivity Gain?

beliavsky wrote:[color=blue]
> Another point. Python advocates often claim it is better than compiled
> languages because the code is much shorter. They rebut worries about
> the loss of safety by recommending unit testing. In a Fortran 95 or
> C++ program, I don't think as many tests need to be written, because
> the compiler catches many more things. If you include the amount of
> testing code when counting the amount of code needed, I suspect
> Python's brevity advantage will partly disappear. Also, I regard unit
> tests to check what happens when a Python function is called with
> invalid arguments (int instead of float, scalar instead of array) as
> low-level, tedious work that I would rather delegate to a compiler.
> Scripting advocates claim that their languages are higher level than
> compiled languages, but in this case the reverse is true -- the
> compiler does more work for you than the interpreter does.[/color]

Interesting thread! One minor nit though: writing the type of low-level tests
you describe above is almost always a no-no for Python programs. Good tests
tend to be geared towards functionality, so that the number and type of tests
correlates more closely to the features and algorithmic complexity of the code
than it does to the language.

Those ultra tedious low-level tests are usually a waste of time because they
end up covering cases that either never happen in practice or cases that are
already covered by tests that cover real functionality. In fact, really the
only time where I've come across the need for those types of tests is in
_other_ languages (C++) because they are more common in languages that require
the programmer to manage more details, and because failing to test those
conditions results in a hard crash of the program (tests like "properly rejects
null pointers passed in" and "doesn't access beyond array bounds").

IOW, in the *worst* case you invest the same amount of time and effort testing
your Python application as you spend testing your C++ (or whatever)
application - I haven't come across ANY case in practice where you end up
investing more effort; in fact I'd say that in our projects we end up spending
considerably less effort because (1) we get to skip precisely the type of tests
you're talking about and (2) the setup/teardown/test code is much more consise
and reusable (which is why in the past we've used Python as the test language
for applications written in other languages).

In theory, yes, you could have a Python function that gets passed a scalar when
it was expecting an array, but in order for that to occur you almost always
have a gaping hole in your suite of higher-level _feature_ tests. With adequate
feature and system test coverage (which you'll need regardless of the
implementation language), the probability of encountering a scalar vs array
error is way less likely than e.g. a null pointer access bug.

-Dave

[Terry Reedy]

Re: Python Productivity Gain?


"Harry George" <harry.g.george @boeing.com> wrote in message
news:xqxbrnvbhv k.fsf@cola2.ca. boeing.com...[color=blue]
> It is common for a ComSci prof or grad student to crank up such a
> study, using undergrad and grad students as the subjects. These
> subjects can generally be coerced to participate ("it is required for
> the course"). For "novice programmer" research, high school students
> are often used. These tend to be self-selected, and ar not
> representative for the general population.[/color]

The key feature that makes a study/experiment statistically analyzable is
randomization of subjects to treatments. So, to compare two languages
(simplest case), you have everyone write programs in both languages, but
randomize the order (half one way, the other half the other way) or you
have one half do language A and the other half B, again randomizing the
assigment. Also, if there is any subjectivity in the evaluation of
results, then the judges should not know the language when judging the
output.

Do the studies you speak of meet these criteria?

Terry J. Reedy