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

[Carl Banks]

Johannes Gr?dem wrote:
> * Carl Banks <imbosol at vt.edu>:
> 
>> Python represents logical nesting the same way human read it, by
>> indentation.  Lisp repesents all nesting with parentheses, [...]
> 
> When you program in Lisp, you (your editor) indents blocks for you,
> which makes it easy to see block structure.  Noone actually manually
> count parentheses.  (All sane editors support paren-matching.)

I know that.  But that's just humans using the editor to count for
them.  The point was you can't eyeball the nesting of parentheses.


>> Python uses infix notation for math.  Most humans were brought up to
>> understand infix.
> 
> Because Lisp has a powerful macro system, it is actually possible to
> have an infix-macro, which lets you use infix-syntax.  And you can
> write macros to support all sorts of weird syntax, if you want.

The kind of person who writes an infix compiler in Lisp is not the
type of person who's going to be daunted by all the parentheses.
We're talking about the popularity of Lisp, which (as with all
languages) is largely determined by people who are not that kind of
person.




>> The reason Python programmers often don't have to think about it
>> is most of the time it's intuitive.  [Evaluation order.]
> 
> And when is it not intuitive in Lisp?  Sure, you can write macros that
> evaluate arguments in unintuitive order, but why would you?  For
> functions, arguments are evaluated left-to-right, just as you would
> expect.

It's not that Lisp goes out of its way to be unintuitive, but you
still can't rely on your intuition because of the many exceptions, and
an understanding of evaulation order is necessary to avoid pitfalls.
Python has a few pitfalls related to time of evaulation; Lisp has
hundreds.

Notes about when a particular form is evaluated are all over the spec.
There are a lot of macros and special forms for which it isn't clear
whether you should quote an argument or not.  Just the fact that there
are macros at all (and that they look just like functions) means the
programmer has to be aware of evaulation issues.

Then you throw compiling into this.  In every compiled language I
know, with two exceptions, it is completely obvious whether code is
evaluated at compile time or run time.  The two exceptions are Perl
and Lisp.  In Lisp, sometimes it isn't even *defined* when code gets
evaluated.  So, the programmer has to guard against both cases.  How
can you do that without understanding evaluation issues?

What I'm saying is, in Python, you can all but ignore time of
evaluation.  You can't do that in Lisp.


> Maybe you're confusing Lisp with Scheme?

I don't know what problems Scheme has that Common Lisp doesn't in this
regard.  Care to elaborate?  Or is that just a common reaction to
criticism of Lisp ("it can't possibly be us, you must be thinking of
that quaint language Scheme")?


-- 
CARL BANKS