Python advocacy

[Paul Prescod]

Ran wrote:
> 
> 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.  

Well this is the most common example of a wildly divergent problem
domain. I've got a few comments from embedded programmers in my mailbox
(even though I excluded ANSI C from the languages I would like to
replace...).

But I think that a constraint imposed by hardware is different in kind,
not just degree, from logically different problem domains like:
"financial computing", "telecommunications", "web interfaces", "GUIs",
etc.

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

Do they make decent code just by turning on static type-checking? I find
it incredible to believe that these coders are so bad that they can't
survive without a type checker but they have no problem with pointer
safety.

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

Agreed. But that is not the way it works. Programmers tell the project
manager what language they should use. Programmers gravitate towards
complexity until they get overwhelmed at which point they revert to
simplicitly (like art movements). It has almost nothing to do with which
language will get the job done.

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

No, there will never be a single language that everyone uses. There is
likely to be a "shakeout" in the next five years that will reduce the
number of languages greatly. I think that after the shakeout there will
be a single language in the VB/TCL/Perl/Python space. It would be better
for everyone (other than the winner's) pride if it was a language that
didn't exist today but only a large shift in the computing environment
could allow a new language to arise and become popular.

> Ah,  but *whose* "simplicity"?  The end user's?  The programmer's?  The
> compiler writer's?  The executing CPU's?  

The programmer's. But, really, the languages I disparaged in the article
do not simplify any of the above. When I worked at a C++ compiler
vendor, we had a special "airline sickness bag" on the wall for when we
recognized another hoop that C++ forced us to jump through.

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

No, Perl and C++ are harder to implement and also to use. The CPU
doesn't find them particularly "simple" and the end user doesn't care.
If we were comparing C and Python then your argument would be more
interesting.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"We still do not know why mathematics is true and whether it is
certain. But we know what we do not know in an immeasurably richer way
than we did. And learning this has been a remarkable achievement,
among the greatest and least known of the modern era." 
        - from "Advent of the Algorithm" David Berlinski
	http://www.opengroup.com/mabooks/015/0151003386.shtml