Why python???

[Alex Martelli]

Michael Peuser wrote:

> Hello Alex,
> this is one of the most exciting topics to discuss, however _slightly_
> off-topic.

Nothing affecting Python as directly as this subject is off-topic here.
You should see the really OT threads on this group (tolerated with more
friendliness than just about everywhere else, mostly).

> Generally I agree with your reasoning. However I disagree with
> some conclusions. We all know peace is the best possible state but there
> is war......

...therefore clearly some in fact think that war is preferable to peace
under some conditions (given that remaining in peace always requires
_some_ concession to the potential adversary; it's far from surprising
that in certain cases those concessions may be regarded as a heavier
price to pay than war).


>> Moore's Law is working in favour of higher level languages even harder
>> than it's working in favour of free but highly efficient OS's.
> 
> There are two aspects:
> (1) More power for same price - this works in favour of 'complex software'
> (2) Same power for less money - this works in favor of 'cheap software'

And software is developed more cheaply in higher level languages than
in lower level ones.  Therefore, both [1] and [2] work in favour of HLL's,
which let you develop more complex software for the same price or the
same software (software of the same functional complexity, but more
often than not somewhat hungrier of hardware resources) faster & cheaper.


>> > will pay $200 for an operating system when the hardware has the same
>>
>> Most Linux use of commercial significance is not happening on such
>> incredibly cheap systems, but rather on reasonably substantial servers
>> (or sometimes even mainframes -- IBM _has_ invested a lot in Linux:-).
>> The issue you mention MAY play a role in ensuring a nice for Lindows
>> (and other desktop-oriented versions of Linux), but the server side
>> is where Linux got its first foothold.
> 
> This is just a scaling. The main argument is the same. The software
> related parts of the total cost of ownership have today become a major
> concern.

In this economic climate, many firms and governments are indeed
"penny pinching" -- not caring so much about total cost of ownership
over the years, actually, but about THIS quarter's bottom line,
THIS fiscal year's deficit.

But were you to reason in terms of proportion of cost, scaling does
not really apply.  Take the pricing that my provider, aruba.it,
offers for lease-based hosting.  The SW component: if you want
Linux it's free, if Windows server 2003, 15 EUR/month.  The HW
and bandwidth components can go from 30 EUR/month for a risibly
configured Celeron (!!!!) memory-starved disk-starved server which
will survive only because it gets so little bandwidth you won't
even be able to play pong on it, to about 500 EUR/month for a
really well configured server for heavy load with huge bandwidth.

So at the cheapest level, it's 30 with Linux, 45 with Windows;
clearly here the SW price does have some importance.  But at good
server levels, the prices are 500 or 515: only a crazed penny-pincher
would consider THAT 3% difference to be a decision factor.

Key issue is, SW price does not scale up linearly with the power
of the HW you apply it to -- nowhere near that, even though my
ISP's policy of "one price fits all" may be extreme.  So, even
though there ARE some crazed penny pincher around these days (and
for good reason, no doubt), which don't look at % factors but
only at absolute possibilities of shaving half a penny here or
there, this isn't as crucial a factor as you make out.

When it IS crucial, it tends to apply to ALL cost factors.  Even
if the license cost of some SW may be a ridiculously small part
of what it costs to operate, say, a municipal government, that
does not matter: most other cost factors are fixed -- the govt
"cannot" just lay people off, at least it cannot politically even
where it legally might (and in Europe it's also a legal problem),
so it saves on toilet paper, paper clips, cost of compilers, or
ANY other factor where it may, no questions asked.  In THIS kind
of situation, the zero-price factor is just as important for a
development environment as for an operating system or the like.


>> Not necessarily.  If common programmers only knew machine language,
>> it would still be cheaper to use any available high-level language,
>> say COBOL, even if you needed to supply training for it (it's not
>> hard to teach COBOL to somebody who knows assembly, anyway -- the
>> reverse is harder).
> I am on your way; maybe they more probably would be trained for some
> "macro language". This is no 'paradigm change'. Most C++ programmers (I
> know what I say!) write C programs.

History proves you are wrong: in practice, COBOL was what took over
the market for business application development, *NOT* macro assembly
as you claim would "more probably" happen.  A paradigm change, to be
sure, but it's what DID win historically.  By ignoring history, as
you're doing, you may not be doomed to repeat it, but you sure do
handicap grievously your chances to predict the future.

(And no crap about "marketing" being responsible for it, please: in
the '60 the _only_ heavily marketed programming language was IBM's
PL/I... and it lost to not-heavily-marketed COBOL and Fortran, as
its technical complexity was just too high on too many issues, in
terms of both programmer training and productivity, and implementation
complexity and resulting bugginess).


>> Similarly, using Python can lower costs even
>> if you factor in training costs (again, teaching Python to good
>> Cobol programmers is quite easy -- other higher-level languages may
>> not be _quite_ as cheap in these terms, admittedly, but still the
>> economics aren't _hugely_ different).
> 
> This argument is valid for:
> - OOP ("Reuse will reduce costs")
> - RAD
> - XP
> - Design-for-testing
> - Rigid configuration control
> - state any new thing you like
> 
> The fact that  a better world is possible does not mean you get it.

Those practices which do increase productivity do tend to get used
more: OOP, RAD and configuration control are heavily prevalent today,
and XP and test-driven design are making great strides.


> Python is by no means a "perfect" alternative to  - lets say: DOT-NET and
> #  - the advantages are difficult to see for persons in power or - I
> mentiones the tool costs - are of minor relevance.

Python may get in "sneakily" -- because programmers love it or because
a desperate pennypincher has no alternative to saving "minor-relevance"
money as it can't attack the major-relevant budget items anyway -- and
proves itself enough that even "persons in power" (which aren't _always_
total idiots) see its advantages.  See the "Python Success Stories"
for many examples.  As the evidence accumulates, Python also starts
getting in non-sneakily, by executive decision rather than by the above
means -- and keeps proving itself.

And Moore's Law is absolutely crucial to this relentless trend.

There many be no "perfect alternative", nor other examples of
perfection in this sublunar world.  Cars aren't *perfect* alternatives
to horse buggies, either.  They don't need to be: they're cheaper and
more powerful by a sufficient margin to have taken over.


> I should as well like to discuss your aspect of programmer's productivity.
> This is an important  factor. However all investigations show that
> programmer's productivity is an unmeasurable quantity. It certainly has to

Once again, you are totally wrong, and moreover, you are wrong in an
assertion that you choose to express in the broadest, unqualified terms.

Lutz Prechelt's study, the best-known example of empirical investigation
of programmer productivity, show Python and Perl ruling the roost, and
grinding e.g. Java into the dust.  This only confirms in a specific case
study the well-know results of the Function Point community: the higher
level a language, the least amount of code per FP it needs, the higher
the productivity in all phases of coding and maintenance.

> do with what the programmer likes to do. If he or she would like to
> program in Python everething would be fine. However most or today's
> programmers like to do what is called "mainstream" (circular reasoning, I
> know) That is a little bit document driven development, some UML charts,
> Visual Studio, something inbetwen C and C++, C# and Java, and MS Office.

As long as those are the skills that employers request, those are the
skills most employees will cultivate, of course.


> This can only change if there is competition. Competition means a Killer
> Application that could be sold for half the price of the nearest
> competitor because the developing costs had been such low!
> 
> Do it with Python then and show it to the world  ;-)

It's been done more than once, and it's being done again as we speak,
many times over -- again, see the Python Success Stories.  Google is
an example that didn't choose to submit all details of its Python
success -- but Norvig, Google's search-quality director, has stated
unambiguously what a crucial role Python has played and still plays
in Google's amazing ongoing success.  The Open-Source Applications
Foundation is doing the same with Chandler, a personal information
manager application.

Once again, it appears that your assertions are based on essentially
zero knowledge about the subjects you're prattling about.


Alex