Python advocacy

[Ran]

Paul Prescod wrote:
 
> It is my observation that over time these differences have moved more
> and more from programming languages into their libraries.

But your observation is based on the applications areas you work in.  My
observations are very different,  because I work primarily on embedded
systems for 8-bit (and occasionally 16-bit) processors.  So I see *huge*
differences among problem domains on a daily basis,  as I split my time
among firmware,  production-level support apps on the desktop,  and
development tools.  And many of those differences are not the sort that
can be reduced by hanging a new library on the run-time.

> The interesting thing is that I haven't yet met a person who gave Python
> a solid try and then said it didn't fit their temperament or abilities.

You're asking the wrong people:  you need to talk to the ones who have
to use/maintain their code  ;-)  I've known several programmers who
would have to be shot for the protection of their customers if we didn't
have tools like lint and compilers with strict type-checking.

> Anyhow, let's say that there are people who naturally gravitate toward
> Perl, others that naturally gravitate towards C++ and so forth. What
> does that mean for maintainability of large software systems?

About as much as the fact that some people gravitate toward tweezers, 
and some toward welding torches,  does about the maintainability of
bulldozers and Swiss watches.  You staff the project with people with
the talents and experience appropriate to the job,  and let the others
find a different niche,  where they can work well.

> Every
> programmer chooses the language that they gravitate towards and then the
> customer worries about the maintenance problem later?

No,  the project manager chooses the language(s) according to the needs
of the project and the availability of programmers and other resources.

> Let's say that you increase the LOC of a project by 20% using 2
> languages instead of 6. Doesn't the reduced maintenance burden offset
> the additional coding time (if any)?

Much of the time?  Yes.  In most cases?  Probably.  In all cases?  No. 
Sometimes,  it won't even reduce the maintenance burden.  Which is not
the only life-cycle cost that starts accumulating after shipment: 
execution efficiency is likely to be a significant factor for most
systems other than single-user workstations.
 
> To some extent, though, you are right. 

Of course I am  ;-)  But not because I said that "[Your] meagre efforts
at evangelism
are not that important".  Because they are:  the ongoing arguments about
what makes tools "decent" (to use your term) are the biggest forces
driving those "evolutionary processes".

The reason I'm right is that I said there won't be any *single*
"survivor" of the evolutionary struggle,  and that the efforts to crown
one's favorite as such are just so much noise.  The software ecosystem
of the foreseeable future will always have its own form of "diversity": 
there will be lions *and* elephants *and* fish *and* seals *and* birds, 
because there will be many diverse "habitats" where the particular
adaptations of each will be needed/advantageous.

The reasoned debates (as opposed to religious wars) may lead to lions
with opposable thumbs,  or elephants that can see in the infrared,  but
there will never be a 2000-pound fish with a mane and wings.  Well,  not
outside the lab,  anyway.

> My personal opinion is that simplicity drives out
> complexity naturally

Ah,  but *whose* "simplicity"?  The end user's?  The programmer's?  The
compiler writer's?  The executing CPU's?  Each has his/her/its own idea
of what's "simple",  and you can't maximize all of them at once. 
"Complexity" seems to be a lot like "energy":  you can *transfer* it
from the end user to one/some of the other players,  but the total
amount seems to remain pretty much constant for a given task.

> so it is only a matter of time before the ugly
> programming languages go away. :)

Does the name "COBOL" ring a bell?  Don't hold your breath  ;-)

Ran