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

[Carl Banks]

maney at pobox.com wrote:
> Carl Banks <imbosol at vt.edu> wrote:
>> 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.  :-)

Whoa--what about all that passing-state-around stuff you mentioned in
another message?  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.


>> 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"?  :-)

No, I've never been a computer science student.  I'm familar with the
concepts in a lot of Knuth's writings, but don't recall ever reading
any Knuth directly.  Is this the one where Knuth claims that any
useful loop can be put in the following form:

loop:
    <do-something>
    if <exit-condition>:
        break
    <do-something-else>

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


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

Yes.  It's a balancing act deciding which control structures are
crucial enough to include.  In this case, and unlike most other cases,
the current control structures and workarounds available are too ugly;
that might justify a new syntax.  But in the end, the idiom is not
common enough.

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.


-- 
CARL BANKS