Scott Schwartz (firstname.lastname@example.org.NO-SPAM) wrote:
> Erik Naggum <email@example.com> writes:
> | ANSI Common Lisp, and even Common Lisp the Language, 2nd edition, specify a
> | language that is, in practice, _routinely_ compiled to code as fast as C,
> | often faster because Common Lisp programmers use better algorithms and have
> | more time to optimize where it is needed than C programmers.
> The catch, as you well know, is that those implementations also have
> huge, expensive runtime systems and slow startup times, so to be
> usable you have to live inside them.
If there was sufficient relevant interest to produce a Common Lisp with
a very small first-time startup (further runs of the free CMU Common Lisp
don't take any humanly noticable time even on my old 486 Linux system),
that wouldn't be technically difficult at all; it just doesn't appear to
be an important goal so far. As a typical Lisp system does already have
facilities to load compiled code dynamically, it could also defer the
loading of major parts of the integrated development system and libraries
until they are needed, or factorize those facilities into shared libraries.
> On this topic, you yourself have
> argued that the lisp repl should be one's shell and that it should be
> judged in that context. While that might be to your taste, you should
> acknowledge that it is totally at odds with how things are done in the
> (much nicer) underlying system, and pretty much proves Ousterhout's
You may find that much nicer, but there are also excellent reasons
why many members of the Lisp community have been preferring the usage
of Lisp as the center of their work. A good implementation of Common
Lisp is so powerful and expressive that one misses something almost
all of the time when working with a less integrated (but at most merely
assembled) system with those primitive "shells". Sure, there are also
arguments for the "part assembly" model, which could be nice if done
really well (however, usually it's crippled) - but don't misinterpret
pressure of stupid mainstream market tendencies as technical arguments.
-- Marc Wachowitz <firstname.lastname@example.org>