ad-hoc vs. planned subsets.

[Skef Wholey <Wholey@CMU-CS-C.ARPA>]

One of the properties of Lisp is that it is VERY easy to write VERY inefficient
programs by choosing inappropriate data structures.  In older Lisps,
programmers were forced to use inappropriate data structures because things
like strings and vectors weren't around.  In addition to the good old Lisp
objects like symbols and conses, Common Lisp provides the data structures that
any other modern programming language provides, and a few useful high-level
data structures (such as hash tables).

A Lisp programmer must choose his data structures well, as must any programmer.
I think it is the burden of the implementor to prevent the "primitives" from
incuring any non-obvious runtime penalties.  I am an implementor, and I live
with that burden.

Given a good choice of data structures and algorithms, there is no real reason
why a Common Lisp program should run significantly slower than an equivalent
program written in a procedural language.  A case in point: The Spice Lisp text
editor, Hemlock, is significantly faster (doing things like text modification
and redisplay) than Oil, a text editor written in Pascal running on the same
machine -- a machine designed to run Pascal!  A lot of careful planning went
into Hemlock, and that planning payed off.  Hemlock does much more than Oil,
and is easily extensible because it is written in Lisp.

A member of our user community here wrote a number of useful CAD tools in Perq
Pascal, and has since been turned-on to Common Lisp.  He tells me that he can
develop programs many times quicker than he could in Pascal, and that the
performance lost by running them in Lisp instead of Pascal is less than 30%,
and sometimes 0%.

By limiting yourself to a subset with a "fast library" and few primitives, you
risk omitting a language feature that might be exactly right for some
application.  I'm willing to bet that a good Common Lisp implementation will
provide that feature more efficiently than a subset with that feature kludged
on as an afterthought.

I can't help thinking that a good deal of the "incredible" slowness of the
application programs you mentioned is due partly to the Interlisp language,
which has been known to provide features at the expense of efficiency -- a fine
thing if you've got a Dorado in your office.  Common Lisp claims heritage to
MacLisp, which put greater emphasis on efficiency.

I don't see how that fact that program X runs slowly in Lisp Y has anything to
do with making subsets of Lisp Z.  There are a lot of free variables there.

--Skef