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

[Vlad S.]

anton at vredegoor.doge.nl (Anton Vredegoor) wrote in message news:<aqltkt$14s$1 at news.hccnet.nl>...
> On Sun, 10 Nov 2002 13:26:22 GMT, Michael Hudson <mwh at python.net>
> wrote:
> 
> >Did you know that s-exps (i.e. the paren heavy Lisp we know today) was
> >intended to be a temporary syntax, and that John McCarthy intended to
> >develop a more familiar syntax for Lisp?  Somehow he never did --
> >maybe because it turned out to be a bad idea?
> 
> That option seems to be available only to people having access to time
> machines. 

What exactly do you mean?

> Wouldn't it be possible to  write a macro for Lisp so that it uses
> newlines and indentation instead of parens?

Yes, it's been done before.
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/0.html
Nobody really cared about the efforts though. Right now, PLT is trying
to do something similar by including tools to let you embed and design
new grammars more easily. The 200 versions come with their example
Algol-60 implementation.

> I know almost all computer languages are indebted heavily to Lisp and
> it still has a lot more to give, but maybe it could accept something
> back? 

"Aha! That explains what inspired some of the idiotic, cryptic syntax
in some functional languages. Stolen from Lisp's garbage can. :)"

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&frame=right&th=78a437568712548&seekm=ur9bjojmm8osad%40corp.supernews.com#link4

That pretty much sums up my views on the topic. Why bother with layers
of parsers to translate cryptic, ambiguous and completely arbitrary
syntaxes to s-expressions (which will likely come out mangled, slow
and unreadable (haha - someone please reply with a parentheses joke)).
Make the algol-like syntax the internal representation, and you get
Dylan, and who wants another pseudo-functional infix language anyway.
There is absolutely no benefit for lisp in algol-like notation - you
lose almost all the macro-construction and abstractive advantages of
having your code represented as a nested (this implies that the
structure of your program is expressed in the code - score another
point for not needing a parser) data structure provided natively by
the language, and get a YAPFL (yet another pseudo functional
language). Last time I checked, Python fit into that category, so you
already have what you say you want.

To each man his own poison; I'll stick with lists, thank you very
much.