Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!news.starnet.net!wupost!howland.reston.ans.net!pipex!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: case for Lisp
Message-ID: <D3L4JB.G0A@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute-alter.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <3h2n14$164@necco.harvard.edu>
Date: Mon, 6 Feb 1995 15:33:11 GMT
Lines: 54

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.  And as you say, it's not an issue
>in a prototype.

I say it is an issue in a prototype, and that tree-shakers are a pain.

Typical Common Lisp implementations produce images and running
systems that are far too large.  Unfortunately, for years and years
people have been claiming that it's not a problem, because "memory
is so cheap" or because "good operating systems" will be able to
handle large images efficiently.  As a result, tremendous damage
has been done to Lisp's reputation by creating the impression that
Lisp systems are inherently very large when in fact they can be
extremely small.

That said, however, I have to note that I have fewer problems with
programs too large for machines and running out of swap space than
some C++ programs seem to.

>	5.  Conversion to C.  How are you going to do the conversion? 
>
>One way to do it is to write code that is isomorphic to C.  Even doing
>this, it will still be a big win to write the program in Lisp.
>
>If you use closures, you're going to have a hard time translating it. But
>if something is impossible to translate into C, it's also impossible
>to write in C, so perhaps the best bet, ultimately, is to take full
>advantage of Lisp and write a program that no competitor using C can 
>duplicate.

There's no much (if anything) that can't be translated into C one
way or another.  That's why it's possible to write Lisp compilers
(such as KCL's or my version of the Franz Lisp compiler) that compile
Lisp to C.  Closures can be handled.

BUT these compilers don't emit C that you'd want to maintain as C.
There are some things billed as Lisp-to-C "translators" that must
do better, but since I've never seen their output I can't say whether
it's good enough.

One way to translate to C is to write a new program using what you
learned from the Lisp one.  That may be more effective than if you
try to restrict your Lisp to what can be translated straightforwardly
by hand (or w/ the aid of tools you could easily write).

-- jeff
