Subject: Re: size of executables?
From: Erik Naggum <erik@naggum.net>
Date: Sun, 16 Sep 2001 13:28:19 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3209635698009992@naggum.net>

* Aleksandr Skobelev <2269@mail.ru>
> I see your point and in general I agree with you. But, in my opinion, it
> would be not bad if Lisp executables could been built without features
> that were not used.

  Why is that not bad?  You keep repeating all these things as if there
  were no reason to explain yourself.  There is.  Your assumptions need to
  be made explicit and open to re-evaluation.

> "Pay only for what you use" -- it is a thing that I like in C++.

  So use C++, then.  I completely fail to see the problem.  If you want to
  use a different language, you actually have to buy the whole package
  deal, not just the bits and pieces you like and then keep some other
  language -- if you want that, build yourself a CL++ environment.

> I believe it can be also implemented in CL realisations, because after
> the moment when a standalone executable has been created, it is not a
> part of a Lisp system more, and theoretically :) all unusable parts could
> be determinated and removed during the building stage.

  The "standalone executable" (the only such thing on modern computers are
  boot loaders, so why you so desperately want a boot loader in Common Lisp
  is beyond me, and I might even argue strongly against writing boot
  loaders in Common Lisp unless you booting a Common Lisp system from the
  bare metal) _is_ the Common Lisp system.  There is no pracical difference
  between the development environment and the "executable".  If you decide
  to remove large fractions of the development environment, you end up with
  a system that is both hard to debug and harder to evolve.  One of the
  great strengths of a Common Lisp system is that you can patch it while it
  is running, and so one of the great features of Common Lisp applications
  that they can run forever (bounded only by system reboot and shutdown)

> On the other hand I can say nothing about is this work on reduction of
> size of Lisp executables is really needed to be done? ...  Well, if
> consider Lisp system as a means for creation complex intellectual and
> probably interactive system, then defenitely not, it isn't needed.

  Certain Common Lisp vendors have positioned themselves such that it is
  financially suicidal to create anything _but_ hugely complex applications
  in Common Lisp.  This means (their) Common Lisp is never used to build
  the kinds of toys that programmers need to build trust in their tools.
  Being able to dump a toy executable like you ask for is therefore highly
  desirable, but it is a completely useless exercise for anything other
  than such building of trust in your tools.  You would never actually want
  to deploy an "application" in C, C++, or Java that did anything similarly
  trivial to the hello, world programs, but the model for building a simple
  program is similar in certain respects to building a large program, and
  that is why the hello, world program is useful in their context.  In the
  Common Lisp context, dumping an image that can be the "application" is a
  very late stage in the application development process, and one of my
  major Common Lisp projects never got that far at all -- it is running in
  the same environment it was developed, and it has been for almost four
  years.  (Some communications slaves were built as runtime images because
  of licensing issues, but we would otherwise not have been forced to build
  runtime images.)

  The hello, world programs are necessary in order to show people how to
  get from source to callable function.  This is superfluous in a language
  where typing in the source code is sufficient to all it.  It is like
  asking how you write a hello, world program in a Unix shell.  Stuff "echo
  hello, world!" in a file, then run it.  Big deal.  The shell is the same
  kind of interactive environment that a Common Lisp environment is, so the
  task of compiling a C source program is that of bringing it into the
  shall's world-view.  Since Common Lisp environments are powerful enough
  to accept a reasonable language (imagine how much more intelligent Unix
  would have been if you could have written interactive C programs in the
  shell!), you do not need bridging source (definition) and usage, and it
  is generally not necessary to bridge Common Lisp environments and the
  shell, either, since starting the application can be arbitrarily complex
  without meaning anything to the user -- just use a shell script that
  fires up the Common Lisp system with the appropriate options.  That is,
  after all, what shell scripts are intended to be used for, and there is
  absolutely no value in forcing every other program to do what the shell
  can do much more painlessly for you, and installing files and stuff is
  already done by package management software (at least on all reasonable
  operating systems), so you only ship one file to your uses, anyway.  (On
  the other hand, no Common Lisp environment I know of is able to build a
  RPM or, much, much preferably, a Debian package, but that is the _real_
  application delivery these days.)

  On the other hand, I would have preferred a Common Lisp system that built
  binaries and used the shared library ("DLL" to Microsoft victims) support
  in the operating system instead of re-implementing all this stuff on
  their own in ways that means you cannot use them with other languages,
  while they still have to be able to use shared libraries to interface with
  foreign function code, so something is clearly wanting in that design.

///