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

[maney at pobox.com]

Carl Banks <imbosol at vt.edu> wrote:
> Well, I highly disagree that changing assignment semantics is the
> solution to this, for three reasons.  First, I have a general distaste
> for anything that returns a value and has side effects.

De gustibus...

> Second, it leads to all kinds of unreadability in the code by people
> abusing it.

I have violently mixed feelings about this sort of argument.  See, for
example, my thoughts somewhere around here (my, big thread we're having,
isn't it?) on the almost identical "it leads people into error" meme.  I
know that "so stop hitting your thumb with the hammer if it hurts" isn't an
adequate response, but boy does it want to escape... as it just did.  :-)

Besides, I think COBOL proved long since that mechanical restraints don't
magically result in readable code.  Pronounceable, maybe...

> Third, it is an incomplete solution.

It's complete enough for me - when the stuff-to-be-done gets too big, then I
consider wrapping it up as a function perfectly reasonable.  As, I want to
point out, was done in the sketch I posted.  :-)

> A new syntax would be the best solution, IMHO.  For example, the
> suppose statement:

Would I be right in supposing that you are not unfamiliar with Knuth's paper
"Structured Programming with Goto Statements"?  :-)

> However, it is not likely to happen because it adds a new keyword, and
> the idiom is not too common.  (Some will argue that it's hard to
> follow, although I wouldn't say it's any harder than else: clauses on
> fors and whiles.)

The real problem is that there is no end to number of special-case control
structures you can find some use for.

> And, getting this back to the topic, you could do this if Python had
> macros.

Macros are too steep a price to pay.  I said that I don't like arguments of
this form, but macros are, IME, far too much associated with code that's
really difficult to understand.  I think it's basically the jargon problem:
the more you're immersed in a problem, the more you tend to use a terse,
contextually inspired shorthand, and the less comprehensible you are to
anyone not so immersed.  Macros let you jargonize your code.

Or it may be simpler.  Macros that let one invent a new [variant] language
may do even more to reveal that designing languages isn't one's strongest
suit than anything else.  :-/
 
> that.  That's why we have Lisp.  Having the occasional useful syntax
> not available (tryexcept anyone? conditional operator?) is a price
> you pay sometimes.

Yep.  That's why I got started on this quest for a more Pythonic way to do
what, in this case, needs doing.  I'm afraid the operator= issue was more of
an inspiration to start the discussion than my real interest.