From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!news.tele.dk!small.news.tele.dk!134.222.94.5!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: size of executables? References: <1hqun9.nv.ln@hermit.athome> Mail-Copies-To: never From: Erik Naggum Message-ID: <3209635698009992@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 89 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Sep 2001 13:28:19 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 1000646899 193.90.206.213 (Sun, 16 Sep 2001 15:28:19 MET DST) NNTP-Posting-Date: Sun, 16 Sep 2001 15:28:19 MET DST Xref: archiver1.google.com comp.lang.lisp:16315 * 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. ///