Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!agate!ucbvax!hplabs!hplabsz!mayer From: mayer@hplabsz.HP.COM (Niels Mayer) Newsgroups: comp.lang.lisp Subject: Re: Is this the end of the lisp wave? Message-ID: <6493@hplabsz.HP.COM> Date: 23 Jan 91 22:25:04 GMT References: <17374@csli.Stanford.EDU> <1991Jan23.080259.19816@Think.COM> <1991Jan23.094925.12728@ulrik.uio.no> Reply-To: mayer@hplabs.hp.com (Niels Mayer) Organization: Hewlett-Packard Labs, Software & Systems Lab, Palo Alto, CA. Lines: 73 Summary: Expires: Sender: Followup-To: In article <1991Jan23.094925.12728@ulrik.uio.no> espen@math.uio.no (Espen J. Vestre) writes: >Second, why is it claimed that CL is "too big"? What does that mean? >That applications tend to take up much space? That lisp systems take up >much space? Anyway, it is certainly possible to make compact CL systems. >My own favourite system takes up only 790K on my harddisk. How much space a program takes up on a hard disk is not very important -- disk is relatively cheap compared to RAM. More important, what is the runtime size of your application? Most of the CL impls I've seen take up megabytes of valuable RAM and swap space; add a substatial application on top of that and 10-50 megabyte runtime images become commonplace. Generally, people won't notice this if you've got a reasonable amount of RAM and the CL process is the one getting most of the use. Typical cases for such usage is in application prototyping. On the other hand, try deliveriing a nontrivial CL-based application in which the applications is but one of the processes competing for resources on the workstation. Even worse, try delivering a CL-based application into a multiuser, multiprocessing environment. You'll be thrashing like crazy in no time. Users will hate you. Customers will hate you. RAM manufacturers will be laughing all the way to the bank. >Clumsy >solutions wrt. to space is not limited to lisp, however. On one well- >known brand of unix work-stations, the whole X library has to be linked >with any application that uses it, which makes even a small clock a >several-hundred-K application. The whole X, Xt and widget set library does not need to be linked in to a X application such as your clock example. Only the parts that your linker determines is necessary. However, much more code gets linked in than is ever used. That's because much of the code needs to be there just incase an infrequentlly used resource is set, customized, altered-at-runtime, etc. It's the moral equivalent of having eval linked in to a deliverable CL program (e.g. there's no way of proving that some function or functionality can be removed given that data can be interpreted and executed). Xtoolkit based applications have a different form of data that can be interpreted -- resources. I find your comparison of CL against Xtoolkit based applications interesting due to a particularly warped view of the Xtoolkit that I hold. Remember that anytime you're using the X toolkit, you are using the nearest thing to Lisp's inefficiency, but packaged in an all-C implementation. Everything done in the internals of Xt is dynamic, and interpreted and very little can be optimized or compiled out at the level of Xt's C implementation (e.g. Xt's dynamic method lookup). However, the customizability provided by the Xt implementation makes applications far more useful, and far easier to integrate into a variety of work styles and environments. Given shared libraries, and multiple applications that share the same Xt & widget-set code, the size of such applications becomes less of a memory burden. ---------- I personally think that Lisp is a wonderful language for prototyping and extending systems at a high level of abstraction. I also think that C is a very useful portable assembly language which should be used when speed and size are important considerations. I use both languages with equal ease inside WINTERP and I believe that hybrid programming in both C and Lisp can give you the best of both worlds. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. * Disclaimer: The above opinions are my own, and do not reflect the official corporate outlook of Hewlett-Packard.