Subject: Re: Help required on Limitations of Lisp
From: Erik Naggum <>
Date: 1997/11/11
Newsgroups: comp.lang.lisp
Message-ID: <>

* David Hanley
| Some 'applications' are actually a number of small executables.  For
| example, the product I'm working on now is ~25 executables.  if each one
| require static binding to ~1.5 MB, w're talking ~40 MB in
| statically-bound code.  It would be nice if some of this could be
| alleviated with a lisp DLL or VM.

why static binding?  would you still need 25 executables in Lisp?

* (whoever)
| > > 3) Programming enviorments are typically several years behind
| > >     those available in many other languages.

that's because those other languages _require_ such environments to be
useful, while Lisp systems get by easily without.  it doesn't make sense to
do more than is necessary to solve a given problem, especially if what you
do extra has zero impact on your earnings and a major impact on your costs.
to make C++ usable at _all_, it _has_ to have those environments, so it
makes perfect business sense to build them, too.  note that C++ programmers
are approaching Lisp programmers in terms of productivity through the use
of these environments, but Lisp programmers are still way ahead.

also note that Lisp was years _ahead_ of other languages for a long, long
time, and that many of the ideas from the Lisp world have been adopted by
the other world.  also note that Lisp systems have remained largely
constant in size since about 1990, even falling in size, while Microsoft
products easily require 100 times more memory and 50 times more powerful
CPUs to do exactly the same ting (as far as user productivity is concerned)
as they did in 1990.  why are people still concerned with the size of Lisp

* David Hanley
| Well, it depends.  If it's going to be distributed, it helps.  It would
| be tough to write 'zip' in lisp with most common lisp systems, because of
| executable size.  However, some modern applications are large enough that
| an extra 1.5 MB might not matter.

if people insist on running every function from the command line, then it's
going to be a problem, but I never saw anybody complain about Word Macros
in Visual Basic on the grounds that you had to load all of Word 7 to run a
snippet of code.  or that to run an X application you had to fire up X
first.  or that to run a Unix command you had to boot a machine, log in and
run a shell.  all of these environments issues are taken for granted.  in
other words: it depends on what you consider your environment.  when most
users spend their entire working day in a single application, what good
does it really do to complain about the size of a standalone program when a
function call would have far smaller costs when run inside an application
the user is already running than a standalone program could ever hope for?


see for GNU Emacs 20-related material.