Newsgroups: comp.lang.lisp,comp.lang.dylan,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!enews.sgi.com!mcsun!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!newsfeed.ed.ac.uk!edcogsci!jeff
From: jeff@cogsci.ed.ac.uk (Jeff Dalton)
Subject: Re: Common LISP: The Next Generation
Message-ID: <Dx50Mu.2uo.0.macbeth@cogsci.ed.ac.uk>
Organization: HCRC, University of Edinburgh
References: <504oa0$1b2@zeppelin.convex.com> <3050338193286393@arcana.naggum.no> <841391580snz@wildcard.demon.co.uk>
Date: Tue, 3 Sep 1996 03:35:17 GMT
Lines: 58
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:22490 comp.lang.dylan:7114 comp.lang.scheme:16692

In article <841391580snz@wildcard.demon.co.uk> cyber_surfer@wildcard.demon.co.uk writes:
>In article <3050338193286393@arcana.naggum.no>
>           erik@naggum.no "Erik Naggum" writes:
>
>> it's pathetic how the C/Unix camp will insist upon loading the dice in any
>> competition among languages, and on top of it, they do not even recognize
>> that they have made assumptions that automatically make them win.  [...]
>
>I agree. Unfortunately, being wrong sometimes doesn't stop people
>from succeeding. I'm not sure who said this, but I recall reading
>something in the August 1981 issue of Byte (the Smalltalk issue),
>"A operating system is a collection of things that don't belong
>in a language. There shouldn't be one." [...]

I happen to greatly prefer having an operating system with
proper memory protection, etc, to the systems (e.g. on Lisp
machines) that more or less got rid of the distinction.
Moreover, I want exiting Lisp and starting a new Lisp to
be a relatively lightweight operation compared to rebooting
the machine.  I guess I'm just funny that way.  ^_^

In any case, while the dice may well _be_ loaded, Lisp systems
could preduce much smaller executables than they usually do.
Indeed, a Lisp could fairly easily produce a "Hello, world!"
program that's as small as a C one.  Suppose the source code
was:

   (format t "Hello, World!~%")

It doesn't need to alloc anything at run-time, so no GC is needed.
Format strings can be compiled.  (If I recall correctly, the XP
pretty printer has conde that does that.)  And writng the string
can be handled directly by an OS write operation.  You might
think that a Lisp would have to arrange for the string to be
aproper Lisp object, but that's not necessary.  Writing a
constant string could be optimized by the compiler.

Ah, soemone will say, what if you write slightly larger
programs.  Then you'll have the GC and all that other Lisp
stuff.  Probably you will.  But such things can be pretty
small.  Most Lisp implementatinos are pretty big these
days, but they can be very small.  (N.B. Lisp does not =
Common Lisp; but even Common Lisps could produce vastly
smaller executables than they typically do.)

Now, standard Lispy run-time stuff (such as the GC) that almost
all programs will want can be shared.  Maybe they're in a shared
library.  That's not all that different from having them in the OS.
(Think e.g. of micro-kernels with various things running as
separate processes.  That something isn't in the kernel per
se shouldn't matter very much.)  Even without shared libraries,
a good virtual memory implementation will let much be shared
(and will avoid touching pages that are not needed).

So, yes, Lisp vs C size comparisons are almost all bogus,
but it's also true that many Lisps could do better.

-- jd
