Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ucselx!bionet!parc!gregor From: gregor@parc.xerox.com (Gregor Kiczales) Newsgroups: comp.lang.clos Subject: Re: CLOS' popularity Message-ID: Date: 29 May 91 23:02:50 GMT References: <9105131105.AA13630@hcsrnd> <9105181833.AA05092@rice-chex> <1991May28.033548.26907@cs.cmu.edu> Sender: news@parc.xerox.com Distribution: inet Organization: Xerox Palo Alto Research Center Lines: 53 In-Reply-To: ram+@cs.cmu.edu's message of 28 May 91 03:35:48 GMT In article <1991May28.033548.26907@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes: From: ram+@cs.cmu.edu (Rob MacLachlan) Newsgroups: comp.lang.clos Date: 28 May 91 03:35:48 GMT I am a Lisp implementor, and a Lisp advocate, but I think a lot of damage has been done by advocating Lisp as being: "The same as FORTRAN/C/Ada, only better". I agree with much of what has been said in this thread but would like to add something as well. I believe there is a chance for Lisp to succeed as a commercial language, and moreover as a commercial language used in delivered systems. But, before this can happen a number of current obstacles to using Lisp together with other languages must be resolved. Here a simple analogy I use when thinking about this. When you build a car, or an airplane, or a building, you don't build it out of one single material, nor do you use one single tool. (Ford doesn't build cars out of steel only with screwdrivers only.) It just wouldn't make sense to do that. A car is a complex system, its various parts must satisfy a variety of goals. The simple fact is that different materials and manufacturing techniques do a better job of meeting those different goals. While there are a few zealots who argue that everything should be built out of plastic or ceramics or some other wonder-material, the common practice is not to do so. Similarly modern computational systems are large and complex and have components which must meet a variety of goals. It doesn't make sense to try and build all of these parts out of the same substrate. Take for example a modern photocopier. The tasks which much be handled include: real-time control (for the paper path and imaging system), window-system like UI functionality (for the control panel), signal processing (for copy quality adjustments) and data logging (for the billing and fault-prediction system). There is no reason to believe that a single programming language, or even a single operating system, is appropriate for all these tasks. We need to understand what tasks Lisp is good for and do a better job of characterizing them. Then, in order to make it possible for Lisp to be used as part of larger projects, our job, as technicians, is to try and work out the technical obstacles to writing large systems using a variety of languages and libraries. The job of our marketing organizations is to try and work out the financial and legal obstacles to writing large systems this way. Only when both of these jobs are done will users be free to write systems in which each individual part can be done using the best tool for the job. Until then, users will continue to use a single tool for the whole job. As long as they are forced into that kind of situation, I think its fair to say they will choose C more often than Lisp.