Why is Python popular, while Lisp and Scheme aren't?

[Alex Martelli]

Pascal Costanza wrote:

> Alex Martelli wrote:
> 
>> Macros let you design a different language on top of whatever language
>> you have (that supports full-power macros).  That's my major beef with
>> them, and ultimately the reason I'm not in the Lisp or Dylan communities,
>> as above noticed.  I don't WANT to use a language that lets me redesign
>> it -- worse, I most definitely don't want to use a language that lets
>> _others_ redesign it, and find myself stuck using and supporting half
>> a dozen different (and mostly badly designed) languages in as many
>> disparate projects.
> 
> How is using a badly designed language worse than using a badly designed
> API? Just don't use them!

That may not be an option -- if you want to cooperate with other people
on a project you need to reach a consensus on the underlying technologies
that are going to be used, whether that cooperation be for monetary gain
or whatever.  Warts in the language can hurt much more than warts in an
API.  Macros let people add warts to a language: good language designers
are few and far between, but macros make everybody into a language
designer, and not all people understand or acknowledge their limitations
in this regard (indeed, far from it: browse this newsgroup's archives
and see how many bad language-changes [mostly additions] are being
requested continuously).

Indeed, macros apart, that's reason number one I prefer Python to Ruby:
Ruby is slightly more flexible in ways that let everybody change some
fundamental mechanisms of the language and build novel and "interesting"
control structures.  With Python (as with most other languages), the
language is bedrock: you're stuck with however it was designed.  I
happen to think it's quite well designed (or I wouldn't be using it,
as it's very much by choice that I am) but I could say the same of
Ruby (the two languages are so close in niches they target and in
expressive power that you have to use a high magnification setting
to tell them apart;-).  But if I were consulting or cooperating on a
Ruby project I would have each and every time to check how this specific
group has changed or enriched the language, spend time and energy in
political battles about which of their "enhancements" can be rolled
back, etc, etc -- have they changed fundamental methods of every
object, or of strings, etc, have they used unnamed code blocks and
Ruby 'iterators' to design weird control structures, and so on.  With
Python, there is none of that -- we can take the language itself for
granted and spend all of our time and energy on higher-level issues.

I like the language to be bedrock.  I'm an engineer, I want to build
useful structures, a solid unchanging base is a good start.  Sure, one
can still build rickety and badly-designed structures on top of even
the best possible bedrock -- that in no way detracts from the usefulness
of such a solid base.

In a peculiar way this ties in to the "batteries included" idea too --
it's why having good and varied standard libraries with the language
matters so much, even though it would be almost as easy to get the
libraries off the net and add them separately.  The vast standard
library provides a shared base, standard acknowledged technology to
be taken as the starting point, and thus saves LOTS of wasted energy
and time in debates about "how should we be doing this, that, the
other".  So one can focus on a few specific issues important to a
given project where one strongly feels that alternatives to the
standard library are crucial -- on one project it may be Qt rather
than Tk, on another, Twisted rather than asyncore, etc.  But, this
is really an aside from the discussion on language features.


> But maybe I am missing something here?!? Could you elaborate more on that?

I think that part of our different viewpoints boils down to the
difference between research in programming and languages (your
field, I believe) and production programming and consulting (mine).
As I said, was research still my job (as it was through the '80s), and 
programming its focus rather than just a tool (as it wasn't even then:
the focus was on such issues as natural language recognition, etc), I
think my feelings might well be different.


Alex