Re: Why does Lisp (SBCL) produce so huge executables?

mac <emailmac@xxxxxxxxx> writes:
I am a big admirer of Lisp, but it makes me wonder why the executable
produced by SBCL (the latest version) that I use on Ubuntu, is so big?

When I started learning CL (and getting the idea), I also have this
thought - wouldn't it be great to write all the programs in lisp
instead of C/C++?

But then it just doesn't work this way, you can't deliver a self-
contained hello-world CL program in under 100k.

So the thought of replacing all the ls, cat utilities weighting at
50mb each is a scary thought indeed.

Silly seems a better term.

The average Unix shell has some set of these sorts of utilities as
built-in features, so it is frequently the case that the shell is not
unlike a Lisp REPL.

And once we have an analogy so direct, it becomes clear that the
*right* answer is NOT to create binaries for these things, but rather
to invoke them from within a Lisp environment.

I haven't done much with this in a while, but was, at one point,
building some wrappers for bits of MH and NNTP functionality in Lisp.
It wouldn't make much sense to run those functions from a Unix shell,
but it surely WOULD be logical to run them in a Lisp REPL.

In the (now-old) "Lisp Machine" environments, that was very much the
idea; you might have a huge "base executable," but it would
immediately include great gobs of stuff.

But you can get creative - I have used CL to generate C code (macros
hide all the boiler plate code from me) and that's a big win for me.

I spent a fair bit of this week writing bits of Lisp code that was
generating SQL schemas. Nobody (aside from me) will ever see the Lisp
code; it has been a convenient way of experimentally generating a
pretty sophisticated schema.
For lisp in general, Scheme implementations usually have much smaller
footprint (because the core is smaller, there's no CLOS built-in for

Usually they're not that much smaller, because having useful sets of
libraries brings them back up in size to be not particularly smaller
than CL...
output = ("cbbrowne" "@" "")
"Optimization hinders evolution." -- Alan J. Perlis

Relevant Pages

  • Re: arc tangent
    ... lisp until a more algebraic notation that was good enough could be found. ... I dare you to cleanly write a Unix ... languages to be invoked to process Unix shell commands with -parms? ... So to emulate nested parameters to a script, ...
  • Re: lisp repl vs unix shell
    ... AM>unix sucks lisp rules. ... who ever wants unix shell if he has lisp prompt? ... what do real Lispniks think about Unix shell, ain't ... If, however, you use the Lisp shell as the commandline environment on a ...
  • Re: (CLtS question) Pathname hosts
    ... >> i had understood the discussion to pertain to pathname designators in lisp, ... >> not in a unix shell. ... by custom and by uncertainty, from a necessary identity with any given file ... "implementation-defined" notation for physical pathnames remain close to that ...
  • Re: (CLtS question) Pathname hosts
    ... >> i had understood the discussion to pertain to pathname designators in lisp, ... >> not in a unix shell. ... (MCL, a Carbon app, still uses the colon for pathnames), and the Unix ... forward slash delimiter in the BSD subsystem (OpenMCL, ...
  • Re: lisp repl vs unix shell
    ... KK> programming to make a useful Unix shell from Lisp. ... KK> level and at the file descriptor level. ...