Subject: Re: C++ briar patch (Was: Object IDs are bad)
From: Erik Naggum <>
Date: 1997/05/15
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++
Message-ID: <>

* Harley Davis
| In my experience, the real killer with Lisp is not so much raw speed, but
| rather excess memory use.

in my experience, Lisp systems start out with a couple megabytes of memory
to hold the entire run-time system, then grow very gradually and maintain a
low system profile as far as memory goes.  C programs that do any useful
amount of work grow rapidly and remain large after the allocated memory
have outlived their usefulness.  they even leak memory when run over long
periods of time.

the real difference between Lisp systems and C programs under Unix is that
the Lisp systems usually do their work in one long-lived process, whereas
the Unix way is lots of short-lived processes.  C's memory allocation is
well suited to this mode of operation, since the operating system does the
garbage collection when the process terminates.  however, the C++ way with
Windows is once again large, long-lived processes.  not surprisingly, C++
does _much_ worse in this department than Lisp systems generally do.

furthermore, if memory usage was a "killer", Microsoft would never have
been able to hoist its disgusting inferiority on the world.  even simple
tools like e-mail clients for Windows use more memory than computers _had_
only a few years ago.  Lisp systems _were_ relatively large, but since they
haven't grown very much, they are now _small_ compared to the cancerous
growth of software written by inferior programmers in inferior languages.

if we work harder, will obsolescence be farther ahead or closer?