Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!netcom4!tmb
From: tmb@netcom4.netcom.com (Thomas Breuel)
Subject: Re: case for Lisp
In-Reply-To: pg@hershey.harvard.edu's message of 5 Feb 1995 14:23:32 GMT
Message-ID: <TMB.95Feb15060552@netcom4.netcom.com>
Sender: tmb@netcom4.netcom.com
Organization: NETCOM On-line services
References: <3h2n14$164@necco.harvard.edu>
Date: Wed, 15 Feb 1995 14:05:51 GMT
Lines: 25

In article <3h2n14$164@necco.harvard.edu> pg@hershey.harvard.edu (Paul Graham) writes:

	   3.  Too Big.  A Lisp image for a _small_ program can be ten
	   times the size of a corresponding executable written in C.
	   Again, you need to think about when and how you will
	   address this issue.  (It may not be an issue at all in a
	   prototyping environment).

   This was another subject dealt with in the articles in the Sept 91 CACM.
   Many Lisp systems come with tree-shakers that can discard the bits of
   Lisp that you don't need at runtime.

You probably missed the last time this thread went around: besides
the rather large runtime, CommonLisp has a serious problem with space
for certain data structures compared to C.  In particular, small
structures containing numerical and/or character data can easily
require several times as much space in CommonLisp than in C.  That is
because of space overhead for extra pointers and type information
that cannot realistically be eliminated in a CL implementation.

Many of the symbolic languages or garbage collected languages fell
into the same trap as CommonLisp by not addressing this issue.
Notable recent exceptions are Eiffel and SML2000.

				Thomas.
