Why don't people like lisp?

[Alex Martelli]

Ville Vainio wrote:

> wallacethinmintr at eircom.net (Russell Wallace) writes:
> 
>> However, this really applies only when you're doing things the
>> language designer anticipated. The great thing I find about Lisp is
> 
> When I'm really doing something the language designer didn't
> anticipate (and the required features don't already exist), I'm
> probably doing something wrong and need to revise my design
> anyway. You can do a whole lot in Python, esp. as you can code parts
> in C if you really need that.

Yes to the latter, no to the former.  Say that you want to do, e.g.,
aspect-oriented programming: that's something Guido definitely did
not anticipate, so Python "out of the box" doesn't support it -- 
that doesn't mean you're "doing something wrong and need to revise
your design" if your purpose is to experiment with AOP.  Sure, you
can download several packages offering AOP for Python (google for
    python aop
for a few thousand links), but each of them will do so within the
normal confines of ordinary Python syntax.  If you want to experiment
with divergent syntax, too, as well as revolutionary semantics, then
those packages can't do it for you, except by implementing a new and
different language, separate from Python though integrated with it.

If your purpose in life is to write good, working applications with
high productivity, then I agree it's most likely suboptimal to play
around with paradigms that are novel, experimental and not (yet?)
well-integrated -- but if your purpose is experimenting with the very
bases of computing itself, such experimentation can't be called "wrong"!

Although it IS quite feasible to integrate most such experiments with
Python, there _are_ other languages that may be even more suitable for
that: Ruby if you don't care all that much about syntax sugar (you can
redefine just about any methods of Object etc to get the semantics you
want to play with -- but it may not have quite the syntax you'd most
like, e.g. you may find yourself having to use f.call(x) rather than
just f(x) because Ruby distinguishes callables from non-callables) --
Lisp (or Dylan, basically an infix-syntax dialect thereof;-) if you DO
care a lot about molding the syntax sugar to your experimental wishes.


>> that when I'm doing something the language was _not_ designed to
>> handle, it's not an "oh shit" problem, it's a "well, I suppose I can
>> do this with a few macros" problem.
> 
> One can always go to c.l.py and ask, only to see that the problem is
> easily solved in plain old Python. I think the benefits of Python far
> outweigh the theoretical scenario that I actually needed some feature
> that isn't there, and could be done in Lisp. Most often the missing

You're taking it for granted that one's actual purpose is just to write
good working applications.  That need not be the case: another might
have the purpose of experimenting with novel paradigms, instead.

> features involve not having a library to, say, access some database,
> and I doubt Lisp has more than Python to offer in that area.

>From the point of view of deploying working applications, yes, you're
surely right.  But it's not the ONLY valid point of view in the world.

> Meanwhile, people are voting with their feet: a lot (thousands? don't
> know the exact figure) of people are taught Lisp (well, Scheme, but
> anyway) at colleges/whatever every year, and they abandon it in a
> blink of an eye after the course (obviously this might be because the
> courses emphasize functional programming). Many even think that C++,
> of all things, is easier!

Sure, there's a "network effect" (in the sense of economics, nothing
to do with computer networks, necessarily;-) that goes to the advantage
of popular languages (C, Java, C++, perl) over less-popular ones (Python,
Ruby, lisps of all sorts).  E.g., it's easier to find add-ons, books,
people to cooperate with, etc, etc.  But it's only one of many factors
to consider in language choice, particularly when you're comparing
languages particularly hard to master, such as C++ or perl, with ones 
that are particularly EASY to master, such as Scheme, Python, Ruby --
teaching one of the latter to people new to it then zipping along with it
may still be faster, for a large enough project, than finding people who
THINK they master, e.g., C++, and slogging through the project while
repeatedly having to engage in bouts of "emergency fire-fighting" and
unplanned tutoring each time some aspects they DON'T master comes up:-).


Alex