Why python???

[Alex Martelli]

Michael Peuser wrote:
   ...
> There is no linear scaling in these issues. It is of no importance whether
> a word processor takes 0.1 sec instead of 0.01 for some operations. It is
> when it takes 5 sec instead of 0.5. 

True, and exactly the same observation applies to most programs: there
are thresholds of response time below which it's indifferent to go; if
the program's response time becomes lower than the threshold, then in
some cases the program will suddenly become useless, in others it will
just decrease in usefulness gradually as it gets slower and slower.

However, response time is roughly HALF of the picture: the other half
is throughput -- amount of work done (perhaps in the background) per
unit of time.  This issue is most important for programs that can
serve multiple users simultaneously, but even for a program and a
machine dedicated to a single user it is still meaningful, as it may
determine, for example, the overall size of document that the program
is able to process in some way before the processing time hits the
applicable threshold.

Moore's Law, which was being discussed here, is crucial to both sides
of the picture -- getting response time under that key threshold AND
enhancing throughput.

> The issues with hard real time
> programs are obvious. 

They're not very different from those outlined above, except that
(by definition of "hard") the time to consider must be a provable
boundary rather than some central indicator such as 3 sigma -- a
response 1 microsec too slow in one case in 100 makes a hard real
time program totally unusable while it would minimally impact the
usefulness of most "normal" programs.


> Most code is not written for home applications or
> some esoteric operating systems as windows but for telecomunication,
> industry microcontrollers, car applications,....

Wrong, just like most assertions you make.  Where do you get your
numbers from?!  Business software expenditure in the UK in 2001, for 
example, was for 42% in services, 38% in transportation and 
communication, only 16% in manufacturing and construction (sorry, 
not sure where the remaining 4% ended up -- check it out on the UK
government official statistics site, www.statistics.gov.uk).  And
note that even for the sectors of communication and manufacturing
only a _fraction_ can possibly have been spent on hard real-time
development -- such business sectors use databases, word processors
and the like just like any othere.  So, offhand, I'd put HRT at
*MAYBE* 25% of business software expenditures, generously.  When
you consider consumer software expenditure, AND all the software
that is not accounted for as "expenditure" (such as most open
source software), I think you'll be lucky to find that as much
as TEN PERCENT of software development falls into those areas
which you grandly proclaim include "most code".  HA.

I hope this helps readers of this thread assess the overall
reliability of your many unsupported assertions.


>> Python is an order of magnitude easier to learn than C++, but it
>> brings really significant programmer-efficiency benefits.  As a
>> result, the argument about training simply doesn't stand up: the costs
>> are lower than the benefits even on a short timescale.
> 
> I know this argument well and have repeated it myself in the days of
> Pascal and  Algol68. Few have listened.....

On Algol68, I would hope so -- that's basically how Pascal was born,
by Wirth slamming the door on the Algol standardization committee as
he realized they'd gone bonkers, and going back to simplicity.

On Pascal, they may well not have listened to YOU (unsurprising,
given the quality of your assertions as above evidenced), but they
did look at reality and it did matter -- for a while, Turbo Pascal
was the leading software development environment for PC's, and it
segued right into the Object Pascal that underpins Delphi, still
quite a viable tool (including its Kylix incarnation for Linux).

Pascal hobbled itself by not developing viable standards, so that
choosing Pascal basically meant chaining yourself to one supplier,
and by not growing up towards application development needs (by
the addition of such indispensable features for the field as
garbage collection).  But it still got its niche and is anything
but forgotten.  Turbo Pascal was the tool used to teach some
programming to both of my kids in elementary school, for example
(it did bring back fond memories of the early '80s, when I was
considered the foremost expert of Turbo Pascal 1.0 on IBM's
internal VNET usenet-like network;-).


> Programmers are generally not trained in their compyna, thea are hired
> including their special language skills.

Most often they're hired -- for reason that may include special skills --
then (in Europe, at least) they stay on and do get training (there are 
lots of gov't and EU subsidies to encourage companies to offer training 
to their employees, incidentally).  But it doesn't much matter if the
training is provided by their company (with or without gov't help), by
the government directly through extended schooling, by the employee
himself investing time and/or money in his or her own skills: in any
case, a programmer these days WILL be using different languages between
the time they start working in their '20s and the time they retire in
their '60s, far more often than not.


>> Total costs are exactly the issue -- the contention is that use of
>> languages like Python really does have a significant impact on that.
> 
> This argument had been used by the most ambitious software tool project of
> the last century, which was DoD's Ada. Very few people will ever believe
> something like that again ;-)

Once again a false assertion: if lots of people had not believed (for
example) about that promise for Java, then Java would never have taken
off (well after Ada's disappointments).  Sure, in the SW industry more
than in most others people have formed a callus against wild promises
for still-on-paper tools.  Python's advantage is that it's a mature,
stable language, and has already been around enought to prove itself
many times over, as the Python Success Stories begin to document.


>> > This is an important  factor. However all investigations show that
>> > programmer's productivity is an unmeasurable quantity.
>>
>> How would an empirical investigation show such a thing?
> 
> Alex gave a hint to a German study. I think he was refering to:
> http://www.ipd.uka.de/~prechelt/Biblio/jccpprtTR.pdf

Yes, that's one presentation of Prechelt's study, and it shows
exactly the reverse of your claim: language choice DOES affect
programmer productivity.


Alex