problems with lisp

[Russ Ross <address@hidden>]

I've used Lisp a bit but not extensively.  I see several things that
would deter me from using it over other available alternatives.
Some of these could be flat out wrong (again, my experience is
limited) and I'd be interested to hear either corrections or
rebuttals to what appear to me to be problems.

The main problem is that there isn't a good choice of a standard
lisp that is well suited for general development tasks.

Common Lisp lacks a good module system, has messy semantics that
reflect its lineage too much, and doesn't have the right (standard)
libraries for things like networking, string handling, and database
access.  It's also big and complicated which reminds me too much of
C++.  Whenever I decide I should finish learning Common Lisp and
start reading up on the nitty-gritty of it I start feeling dirty and
grinding my teeth.

Scheme has cleaner semantics and is much simpler, but it takes it
too far.  There are no standard libraries for anything.  R5RS Scheme
is way too minimalist as a starting point for most projects so
picking a particular implementation and extension becomes mandatory.
Who wants to lock his company into someone's research project or be
at the mercy of someone's design whims?  While I've no doubt that
there are stable and useful Scheme environments out there, none has
wide support and visibility.  It's a strange problem, since Perl and
Python and OCaml (and many others) are all like this, but somehow it
feels more risky when it's a monolith of extensions to a standard
rather than the standard itself.  Irrational, yes, but we've already
seen that rational isn't all there is.

Most (all?) lisps like to bundle a whole runtime environment
including a compiler with every application, so it becomes very
heavyweight to distribute anything.  Yes, perl and python do this
too, but you can normally expect the python on someone else's system
to run your script okay (someone else's CL or Scheme with all its
extensions may not be the same as yours) and they don't claim to be
high performance compiled code, either.  I want to be able to make a
self-contained, statically linked, native executable that doesn't
require me to buy a new hard drive.  Java suffers from the same
problem, and that's part of the reason you don't see all that many
end-user Java apps.

Performance is still a bit of a sore spot, too.  I hear that tuned
lisp code runs as fast as C code, but I'm still sceptical.  I
recently implemented a fairly simple solution to the ILC programming
contest in both CL and OCaml.  I wrote it first in OCaml as an
exercise to learn the language and then ported it to Lisp.  It was
a purely functional solution and I was careful to use tail calls
when possible.  The two solutions are almost identical in structure,
but the lisp version is about 10x slower.  I tried it with two lisp
compilers (clisp and gcl) and they were about the same.  I'm sure a
more experienced lisp programmer could tune it up nicely, but I have
much more lisp experience than OCaml experience and I was shocked
by the result.  I don't trust a language where the clean, simple
approach is the slow one and requires careful annotations and
program restructuring to work around the idiosyncrasies of the
language.  With Lisp it seems like there are two languages: the
simple one you teach people and use to demonstrate its virtues, and
the real one you use for high performance implementations.  Can't
Simple Lisp be the same as High Performance Lisp?  So far it sure
seems to work for OCaml.  Pattern matching meant the OCaml code was
much more transparent as well (and I'm saying this as a complete
beginner with OCaml and ML in general).

Please, tell me where I'm wrong, or suggest ways to improve the
situation.  I'm sure there are lots of factual errors, but perhaps
those will indicate some areas where the lisp community is doing a
poor job educating the public (and I'm probably just being stupid in
other cases).

Contrary to how this sounds, I really like lisp.  I like macros,
continuations, functional programming, prefix notation (at least I
don't mind it that much), and parentheses (see prefix notation).  I
just don't think its problems are all related to peoples' fear of
continuations and garbage collection.  I think the lack of a modern,
practical standard that facilitates efficient implementation and
convenient distribution plays an important part, too.  Maybe Arc
will fix this, maybe PLT Scheme just needs to rename itself as
Java## and pretend it's a new language.  Somehow, we need to
find/invent a lisp that is simple, stable, standardized (even a de
facto standard) and has modern libraries, and rally behind it to say
"this is what we mean when we say you should be using lisp."
Pointing to CL and R5RS Scheme raises too many justifiable doubts
and the others don't have enough consistent backing within the
community to be credible outside it.

- Russ