Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Lisp Eval in C or C++
Message-ID: <15890@smoke.brl.mil>
Date: 18 Apr 91 16:41:13 GMT
References: <11809@dog.ee.lbl.gov> <4434@skye.ed.ac.uk> <1991Apr17.170547.19511@dsd.es.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 21

In article <1991Apr17.170547.19511@dsd.es.com> bpendlet@dsd.es.com writes:
-In a commercial environment your sales will be higher if you run on
-the computer the cutomer already owns. Cutting your memory usage in
-half can more than double your sales. And you won't sell anything
-today if you need next years processor to make it run acceptably fast.
-The origninal poster said "large." The company I work for sells a
-"large" LISP application. Even compiled it can bog down a 128 meg
-R3000. Not mention that having the application "go to lunch" for 5
-minutes at random times while it is garbage collecting is a serious
-user interface problem. Customers Will Not Accept It.
-So... as much as I like LISP I don't think it is a good language for
-writing commercial applications.

While this isn't much relevant to C as such, this is the newsgroup
I saw the above in, and I feel obliged to point out that Lisp
implementations need not be large, nor slow, nor perform garbage
collection in a disruptive way.  Incremental garbage collection
techniques have been published for many years now (I think I saw
one in CACM not long before it turned into a yuppie magazine).
There are even special hardware architectures (Lisp machines) for
people who are heavily into Lisp-based applications.