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

[Martti Halminen]

Alexander Schmolck wrote:

> Sure, loop isn't the only iteration construct, but that doesn't really make it
> any better, does it? Especially given that all suffer from the fact that they
> only work on a quite small number of containers.

Given that every "container" in the language has sufficient iteration
constructs to handle them, I don't see this as a problem.

> > Except that those are rather new languages in comparision, from a time
> > the machine performance had already risen to acceptable values. For
> > comparision, at the time Lisp Machines were the fastest workstations on
> > the planet, they had clock frequencies like 4 MHz. The competition ran
> > 16 MHz Motorola 68020:s.
> > (Cray 1 had 80 MHz, IIRC.)

> This seems a curious argument to me: Ansi CL is about 1994, so it is actually
> newer than python and perl. The fact that things called "lisp" had been around
> before than should only have made it easier (bigger potential user base,
> greater maturity, efficient compilers etc.) for CL to compete against those
> newcomers.

The final ANSI CL standard was approved in 1994, but that doesn't mean
that the language sprung into existence from nothing at that time. The
standardization process started in 1981, when the major pre-CL Lisp
implementation groups got together to start creating a common language.
Steele's book "Common Lisp: the Language" was published in 1984; the
biggest missing piece was CLOS.
The second edition, in 1990 contained most of the stuff that ended in
the standard.

> > No such thing as "iteration class" in the language: Lisp had already
> > existed for a quarter century before it got a standardized object system
> > (plenty of non-standard, non-compatible versions before that), so the
> > control flow constructs are rather othogonal to the object system.
> 
> Sure, but a reason is not an excuse (there are also plenty of reasons why C++
> OO leaves much to be desired :)

Nothing you have written has shown an "iteration class" as anything
desirable, either. 

> > I fail to see what is so hard in that. Obviously you have to design your
> > own wrapper class if you want similar behaviour from different data
> > structures, given that the language doesn't have it built-in, but as you
> > yourself show, any given operation is only a few lines.
> 
> But that is besides the point. The python ``x = cont[indx]`` will likely
> continue to work even if I choose to replace ``cont`` with some other
> container type later. Same for ``for i in cont: ...`` etc. This is a fairly
> important abstraction barrier.

If I didn't misunderstand the Python Reference Manual, that would
require stuff like __len__, __getitem__, __setitem__, __delitem__,
__iter__ to be written by you for it to work. 

> OTOH ``(let ((x (gethash key hash)) won't. T Sure, I could go along and define
> my own generic accesor functions (CL is powerful enough for that) 

(defmethod gethash (key (hash my-hash-table-type))
   ... whatever needed for my own stuff)

(defmethod gethash (key hash) 
     (cl:gethash key hash));; default to normal

If that was difficult in your opinion, we have different definitions for
difficulty.

> >                                      ;; *why* this arg-order?
> >                Why not? It is consistent with most of the language, [...]
> > ELT probably for similarity with AREF.
> 
> Well, if you prefer then elt is inconsistent :)

Sure it is. We are talking about a language that had as one of its
primary design criteria at least some compatibility with existing code
bases in its predecessors, so many design warts had to be retained.
Obviously not a problem for people getting to define their language on a
clean slate.

> Well maybe in theory, but not in practice. The LOOP macro is
> 
> A) vendor specific, if I'm not mistaken. Although you could certainly get your
>    hands on a portable LOOP implementation, doing so might not be without risk
>    (for one the semantics might be subtly different, esp. given that LOOP is
>    often thought to be underspecified)

It is a risk for your own code, but as you would be defining the
semantics, however underspecified you like, that is your problem. The
system continues to run its built-in version for its internals
regardless of what you do in your own code (assuming you did that in
your own package, which is the only sensible way unless you actually
know what you are doing.)
 
> > complex already for most people.
> 
> Well yes, but not sufficiently general. The for loop in python is not complex,
> but more general in that it takes an infinite variety of container classes
> (including lazy ones, which obviously adds expressiveness). And I should
> suspect that people would actually like to extend loop if it weren't such a
> nightmare (also note that e.g. emacs's (cl) LOOP *is* extended).

If you like the Python looping constructs better, it is possible to
implement those in CL. Feel free.

> But why shouldn't one want to have e.g. a hash-table that
> always returns a default key instead of nil, just as a trivial example?

As a trivial example, that is already implemented, see the optional
argument for gethash. If you wanted to define the default in
make-hash-table, you could define your own class to do it: wouldn't need
to be a subclass, though you would have to define a few of the
hash-table functions as methods; most of those would be two lines of
code.
 
> I think you are conflating conflation and abstraction here :)

That may be the case, though I have never before in my life used the
word "conflating" and would have to find a dictionary to tell me what it
means.

> Overloading `+` to perform concatenation as well as addition is IMHO a really
> stupid idea, because they have entirely different semantics (and you can even
> end up with cases where you'd really like to have both concatenation and
> addition on the same type: e.g. numerical arrays).

Hey, we agree on something! :-)

> Unified item access, setting and deletion OTOH is an abstraction and thus
> helps to produce better code. If you disagree, try replacing all instances of
> SETF in your code with SETQ. 
Given that they do quite different things, I fail to see the meaning of
this. For that matter, I prefer SETQ when handling symbols: it is less
dangerous.

>Or better yet, all instances of (+ float float)
> with (+. float float), a la ocaml :)

Gives an undefined function -error, as the language doesn't have such an
operation. What does it do in ocaml?

> > Now what tools did Python have to define your own control flow
> > constructs ? :-)

> Well, for some cases where lispers think you'd need macros the iteration
> protocol and generators are actually enough (and, I guess, also better). Of
> course there are quite a few things you can conveniently do with macros that
> are awkward in python and CL has many cool things python hasn't -- but I
> really think iteration and containers are better done in python.

That may be if you are happy with just that. Quite often in Lisp
programming the datastructures are trees, graphs etc where a
single-dimensional iteration is not what is needed, so it is not such a
holy grail as you make it to be.

At one level it is a question of stylistical freedom: in Python you
program in a language which looks like Guido likes it to be. In CL you
can program in a language that looks like anything you want it to be,
assuming you consider the effort worthwhile. Not all do.

--