Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!bbn.com!archive.bbn.com!aboulang From: aboulang@bbn.com (Albert Boulanger) Newsgroups: comp.ai Subject: Re: Lisp Eval in C or C++ Message-ID: Date: 13 Apr 91 20:44:48 GMT References: <1991Apr4.182329.5513@searchtech.com> <11809@dog.ee.lbl.gov> <4434@skye.ed.ac.uk> Sender: news@bbn.com Reply-To: aboulanger@bbn.com Organization: BBN, Cambridge MA Lines: 25 In-reply-to: richard@aiai.ed.ac.uk's message of 5 Apr 91 12:29:29 GMT In article <4434@skye.ed.ac.uk> richard@aiai.ed.ac.uk (Richard Tobin) writes: I agree. There seems to be a rush to convert Lisp systems to C (or C++) just at the time when the standard complaints about the size and speed of Lisp implementations are becoming irrelevant. Memory really *is* cheap - I just bought 16Mb for my home machine for less than 600 pounds - and processor speeds are increasing so that if you need to double your speed the easiest thing to do is wait a year rather than rewrite in C. Add to this the advantages of built-in garbage collection and extension language, and Lisp becomes the obvious choice. Sadly, the path of going C++ will be taken and by the time all the infrastructure is there (with a lot of blood and sweat and money) people will realize that they come out about the same. Take a look at the Saber C++ environment for example. Not really integrated yet and just as fat as lisps. Another current trend is towards low road solutions to problems because of the current "persona" of world-events. Time flows on in a quasi-periodic way. I can't wait to see what Moon is up to at Apple. Albert Boulanger aboulanger@bbn.com