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

Alexander Schmolck a.schmolck at gmx.net
Wed Nov 20 19:40:17 EST 2002


Kenny Tilton <ktilton at nyc.rr.com> writes:

> 
> > This initial investment is unlikely to be made even by many professional
> > programmers who might well profit from using CL, let alone normal users who
> > just want to customize their applications, or scientists who need to do a bit
> > of programming to handle their data.
> 
> Gotcha. well to me this is more about the many libraries available off the
> shelf for Python or Perl thx to the great open source phenomenon, not about CL
> being harder to learn.

No, I don't think libraries are key. For example, I can imagine plenty of
reasons why CL is much better suited for numerics than python. It has a more
sophisticated number system, it produces faster code and macros would make it
feasible to write extremely readable code (even with infix, postfix and
what-have-you) that gets simplified and compiled to something very efficient
(a la the series package, e.g.). Plus, it has resumable exceptions (quite
important if you have just calculated something in an interactive session and
it took 5 hours) and its interactive features are still better in many
regards, making it more suitable for exploratory programming. 

Python, OTOH, doesn't allow the definition of new operators, hasn't got
multimethods and doesn't even lift constant expressions out of
loops. Nonetheless, there is now a quite vital scientific community in python
and I doubt that the fact that python generally has more libraries was of
prime importance (what you mainly need are good numerical libraries and
plotting; good plotting python still doesn't have and the numerical libraries
are largely there because scientists have been attracted to python, not the
other way around). CL even has freely available (albeit superficially dodgy
looking) lapack bindings and a library for infix math. I expect that the
impact of the numeric community will over the next couple of years resolve
many of the performance issues python currently has. I might be wrong, but if
I'm not CL could loose yet another one of its remaining key advantages (being
high-level but quite fast).


> 
> 
> > I really wonder what your basis for thinking CL to be very approachable
> > is. Specifically, what language(s) do you think would be *less* approachable
> > to a "normal" person than CL? Even perl, which is hideously complex (unlike CL
> > which is complex, without being hideous), is more approachable in that you can
> > do something worthwhile without learning much about Perl ...
> 
> Again this is because of the library code available, yes?

Only partly. Perl is useful *without* any libraries and (much) programming
competence (pace Naggum). That is because it was originally designed to solve
a particular and relatively narrow problem. That is, you could use it for
something productively while learning it. Specifically, "productively" means
*better* than other stuff you already knew or would need to invest an equal
amount of time in order to learn.

> 
> > How about the following criteria for approachability of a language:
> > 1. it should be easy to do conceptually simple and common things
> 
> > 2. it should be easy to do something useful with it
> > 3. it should be easy to read other peoples code
> > 4. it shouldn't have too many surprises in store (e.g. undefined behavior)
> > I think CL fails on all these criteria, for example:
> 
> > 1. operations on files and directories.
> 
> 
> I don't deal much with that sort of thing in my apps, but I did do a poor
> man's project manager for a CL (before I got up to speed on DEFSYSTEM) and I
> do not recall any problem If Python has a lot of that, is that because it was
> developed for that kind of thing?

Python was developed as a scripting language, so yes. You might not have had a
problem with it, but explain it to unclued windows user (and I think he'll
also have to download some extra libraries to have certain rather basic
operations available in a portable manner).

> 
> 
> > 2. try to write something in 1-100 lines in CL that couldn't easier be
> >    written in e.g. python.
> 
> I am guessing you mean something where the Python programmer would be able to
> call on libraries? Mind you, I am just getting started on Python, but CL can
> do quite a bit in a little code if you are just talking algorithms. Maybe we
> should have a code-off (ala cook-off). :)
> 

Anything that is actually useful will do (no need to involve lots of
libraries). I'm all open for code comparisons, which are often quite
instructive. 

> 
> > 3. just think of how many ways there are to express quite similar
> >    conditional or looping constructs.
> 
> You mean if, when, and cond? when you can ignore, tho most of us consider it
> more self-documenting. cond is just if-elseif-if.
> 

Well, of course there are more (unless, ecase, case, typecase etc.), and
learning all the looping constructs presumably takes longer than to learn the
basics of python. But it is not just that there are more constructs (I don't,
in fact, see much of a problem with if/unless/when/cond, because I think it is
relatively clear which one to use in a particular situation; looping is a
different matter, though), it is also that you can express relatively simple
operations with them in many more ways than in python (because python clearly
distinguishes between statements and expressions). This comes of course at a
cost, but that really simple things almost invaribly look the same in python
is a great plus (not just over CL but also over perl).

> 
> Dolist, dotimes, and the multi-variant do? I don't use Loop, but I think I'll
> break down (after seven years!) and learn it RSN.

:)

> 
> 
> Anyway, is a rich language less approachable? I just started with a subset and
> was productive right away (meaning that as I learned more I had a laugh
> looking at code written in the early days).
> 
> 
> > 4. try e.g. modifying constant lists or writing a LOOP with undefined
> >    behavior, or modifying the (string) keys in a hash-table.
> 
> So use C++ and you won't shoot yourself in the foot (or get much done either
> <g>)

What??? C++ and not shooting oneself in the foot? You're surely joking?

> 
> 
> By approachable I mean:
> 
>    the syntax is very simple: (<verb> noun noun ...)


Yeah and assembler syntax is also real simple. Of course assembler syntax is
*always* really simple, unlike say, CL which sports LOOP and FORMAT,
readtables etc.

I have always been baffled by CLers praising the accessibility of lisp's
simple syntax in the same breadth with LOOP and FORMAT (and the syntactic
malleability of CL thanks to macros and readtables in general) :)

And of course simple syntax != approachable. In fact there are at least two
reasons why:

1) it's unfamiliar
2) more importantly: it's easier to write down things that are syntactically
   legal but don't make sense (which is why the pedagogically oriented plt
   people offer only crippled scheme in beginner mode, if I remember right).

Also, our visual system just can't parse 8 trailing ')'s. [Yes I know, people
go by indentation and so do I when I write (emacs)-lisp, and I concede that
all the parens are not as much as an issue as people would have you believe;
but still having things in your code for the benefit of your editor rather
than yourself seems in violation of SICPs famous commandment about programs
being there first and foremost for humans to read. Furthermore, if the parens
are really no problem at all, why do next to all scheme's now (stupidly, I
think) allow '[' and ']' as alternatives?].

I'd be really interested to see what some prefix based mixture between python
and lisp would look like, BTW...


> 
>    interactive (I would say interpreted but in fact some CLs silently compile
>    interactive forms and execute the binary)

Yep, violent agreement here and indeed I wouldn't even consider using a
language that isn't interactive.

> 
> 
>    documentation available at a keystroke, and apropos to search for stuff you
>    suspect is in the language

Yep agreement again, and of course python has docstrings and the corresponding
facilities (unlike say, scheme which for that reason alone sucks [just to add
a bit more controversy :)).

> 
> 
>    true garbage collection (I am /not/ looking forward to reference counting
>    or the hoops one has to jump thru to handle cyclic refs)

Python's gc might be crap, but not in a way that affects your programming
(unless you write C-extensions), since cyclic refs are handled fine, since
some time now.

> 
> 
>    untyped variables

Well, maybe assembler (or perl) is really what you're after then :) (Maybe I'm
wrong, but I thought that the "correct" usage is that both CL and python are
strongly but dynamically typed?).

> 
> Stuff like that. But I am just talking about the language per se, not what
> libraries are available off the shelf. I lean, Lisp is growing, libraries will
> follow. It's a bootstrapping process: more Lispers ->
> 
> more libraries -> more Lispers. And that /will/ be welcome.

Hmm, but what makes you so optimistic that this will happen (it would be nice,
I have to admit)? I mean, CL has been around for quite some time, without ever
catching on, despite the fact that it offered *enormous* advantages over
languages that where more common at the time (C(++), Pascal etc.), maybe first
and foremost gc. By now that gap has narrowed considerably, python, ruby and
even perl (yuck) share many of the key benefits of CL, but not many of its
deficits. So why would you expect people to switch now, for apparently less
pressing reasons then say, 5 or 10 years ago?

I suspect one could try to argue that the success of java/perl/python (all
really just dumbed down versions of CL, a Lisper might say), has helped to
overcome many of the silly prejudices that prevented lisp's adoption. In other
words CL was too far ahead of its time, but now that everything is moving into
its general direction, one might as well go for the real thing. I'm not
entirely sure that I buy this argument, but maybe there is something to it.

I'm certainly willing to concede that CL still has many strong points when
compared to python, but I think Lispers are too ready to dismiss the fact that
the reverse is also true, *ignoring* popularity and availability of
libraries. I think a (informed) discussion of the respective strengths and
weaknesses of CL vs. python might be quite instructive, for both CLers and
pythonistas.


alex

-- 
Alexander Schmolck     Postgraduate Research Student
                       Department of Computer Science
                       University of Exeter
A.Schmolck at gmx.net     http://www.dcs.ex.ac.uk/people/aschmolc/



More information about the Python-list mailing list