Path: utzoo!attcan!uunet!husc6!rutgers!att!ihlpf!jdu From: jdu@ihlpf.ATT.COM (John Unruh, NY9R) Newsgroups: comp.lang.lisp Subject: Re: Unix Lisp Environments (why the slow evolution) Message-ID: <8585@ihlpf.ATT.COM> Date: 25 May 89 12:09:05 GMT References: <31670@sri-unix.SRI.COM> <469@skye.ed.ac.uk> Reply-To: jdu@ihlpf.UUCP (55224-Unruh,J.D.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 31 In article <469@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: > >I guess some of the Unix Lisp vendors are under commercial pressure to >make Lisp fit better with conventional languages and conventional ways >of doing things rather than make systems for Lisp hackers (such hackers >being in limited supply). There is often also a strong negative reaction >to Lisp systems that are many megabytes in size. To some extent this is >unfair, because calculations of the size of C systems tend to omit all >the things C gets "free" from Unix, but it is not completely unfair. > There is one big distinction between the things C programmers get from the UNIX (R) Operating System and what a LISP programmer gets from a good LISP system. Ususally the tools used for C programming reside on the disk except for the moments when they are in use (modulo the sticky bit). If a tool (especially a large one) is used in a LISP image, it increases the size of the LISP image's virtual memory. If the LISP implementation is good at saving memory, programmers tools will be autoloading files of some sort, or at least not be bound into the image in such a way that every delivery system must have them. Many machines have limits on the maximum process size, and have problems with really big processes. This may be an artifact of how conventional programming languages work. Most C programs are fairly small, and the environment is not integrated in the same way as a Lisp machine, so the whole thing tends to be less memory intensive. -- John Unruh AT&T-Bell Laboratories att!ihlpf!jdu (312)979-6765