Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage From: kanderso@BBN.COM Newsgroups: comp.lang.clos Subject: Re: CLOS' popularity Message-ID: <9105231427.AA09586@cheops.cis.ohio-state.edu> Date: 23 May 91 14:10:59 GMT References: <16144.9105222015@subnode.aiai.ed.ac.uk> Sender: welch@tut.cis.ohio-state.edu Distribution: inet Organization: CommonLoops Lines: 92 Errors-To: commonloops-request@cis.ohio-state.edu Sender: commonloops-request@cis.ohio-state.edu Date: Wed, 22 May 91 21:15:01 BST From: Jeff Dalton Subject: Re: CLOS' popularity To: "Walter E. Gillett" , tusveld Cc: commonloops@cis.ohio-state.edu, gillett@ai.mit.edu, gillett > My impression is that industrial use of LISP/CLOS is largely confined > to research labs and that its use is, if anything, declining. There are certainly older Flavor based systems in industrial use. For example, ALCOA has several Flavor based applications in their plants. That is my impression too. However, it seems rather strange that when machines are becomming so much faster and memory so much cheaper we find people thinking it will be a big win to move from, say, KEE to ProKappa. The advanatges of a C-based system are relatively less than they used to be, I would think. Yes, from what i've read ProKappa sounds like a cleverly disguised LISP in C clothing. This certainly may have some marketing advantages these days, but who knows about technical. As time goes on, it may be that C looks at lot more like LISP. For example, garbage collection is a major issue in C++ these days. > ConSolve is considering porting SitePlanner to C++ because of problems > with LISP. Those problems are (in order of importance to us): > > 1. Performance. LISP code is always significantly slower than C code, > even if one works hard to optimize it. I have encountered a number of cases where Lisp code was faster than C or just as fast, but perhaps they are too exceptional. There are also cases where Lisp is slower for no good reason, so far as I could tell. So I think there is room for Lisp to do better here, at least for some applications, and I'd be interested in knowing what cases Lisp handles poorly. The various Lisp implementors may be interested too. I'd be interested too. Certainly vendors have worried a lot about fixnum arithmetic, etc. Unfortunately, in certain implementation LISP will loose over C. For example, in some implementations of floating point numbers it is hard not to cons unnecessary floats. It is also unfortuantely quite easy to write very slow programs in LISP that you would never think of writing in C. One example is (reduce #'+ (mapcar ...)). > 2. Isolation from mainstream software tools. C programmers can use, > for example, the Motif and Open Look GUI toolkits directly. LISP > programmers either have to build a foreign function call interface to > a C-based application or wait for someone else to provide one. But the foreign function interface is a good way to get to this "mainstream" software. If you thought about it, you might be able to write the interface automatically. You could even think of LISP as the glue that holds your C together. This might give you most of the best of both worlds. I've only read about programming in C using Motif and Open Look, so correct me if i'm wrong, but it seems like the first thing they do try to get around some of the things C is missing - namely lists, keyword arguments, and closures. This forces one to program in a style that looks akward to me. The interface to such tools is simple in some implementations. However, you are right that the implementors have to prepare the ground for you and that your code will be at least somewhat implementation-dependent. An approach that works well for some applications is have the graphics code written in C but running in a separate process connected to Lisp by a pipe. Windows, menus, etc are represented on the Lisp side by a "handle" such as, perhaps, a string like "window-1". Although there isn't any standard way to make such a pipe connection, it's fairly easy to do it in most Lisps. > 3. Memory hog. The base development image for Sun Common LISP takes > 14 MB! While there are tools for reducing delivery image size, the > results are still much larger than a comparable C program. This is indeed a major pain. I think LISP can learn a lot from C, but what is a comparable C program to Sun Common LISP? What are we willing to leave out to make it smaller? k