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

[maney at pobox.com]

Carl Banks <imbosol at vt.edu> wrote:
> Whoa--what about all that passing-state-around stuff you mentioned in
> another message?

I'm trying to imagine what I described that has anything to do with this
next bit, and I keep failing.

> What if you have more than one value to assign (that would need to be used
> inside the if clause)?  Sorry, but I must disagree again.  It's an
> incomplete solution.

I never said it was a contender in the "generality for the sake of
generality" sweepstakes... but then, in light of OP's question and my own
feelings about Python and Lisp and the other languages mentioned, I wonder
if that (gftsog) might not be an important part of the answer to his
question.

Anyway, to address your challenge.  So, how would you return a set of
objects from a function call in Python in other circumstances?  Supposing
that assignment evaluated to the value assigned, how might you use that to
extract the portion of the set of values that's needed for the condional
test?

> No, I've never been a computer science student.

Neither have I, in any formal sense.  Just a life-long learner (god, I hate
that phrase, but in this case it's both apt and brief).  One of my
most-prized posessions is a literally falling-apart (so-called perfect
bindings are not; not at all, at all) copy of _Classics in Software
Engineering_ (ed. Yourdon), and Knuth's article is a good part of the reason
I treasure it.

> What specifically about the paper you mention is contrary to my
> suppose clause?

Nothing that I can think of.   Rather, your ready hand at whipping up some
new flow-control syntax reminded me of Knuth's paper, for he does that more
than a few times there.  Of course, the motivations are rather different,
since Knuth's purpose is to replace "ugly" but efficent code (with those
gotos mentioned in the title) with structured code; this leads him to invent
a number of variant flow-control structures that capture the shapes of the
efficent solutions in a cleaner, less general for than gotos.

> I would say creating a new syntax for the sake of this uncommon idiom
> isn't much more ridiculous than changing the assignment semantics just
> for this uncommon idiom.  They are both big changes for a small
> problem.

Quite likely.  Again, I wasn't really all that interested in arguing for the
addition of operator= sematics to Python.  That was a jumping-off point that
led from a thread I was swimming through to my real interest, which was how
to do what needed doing in Python as it exists.  Not that I haven't enjoyed
the digression.  :-)