Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage From: jonl%kuwait@LUCID.COM (Jon L White) Newsgroups: comp.lang.clos Subject: CLOS' popularity [footnote: Goats, Wolves, and Sheep] Message-ID: <9105300406.AA01976@kuwait> Date: 30 May 91 04:06:17 GMT References: <9105231427.AA09586@cheops.cis.ohio-state.edu> Sender: welch@tut.cis.ohio-state.edu Distribution: inet Organization: CommonLoops Lines: 86 Hmmmm, Walter sure has "pushed a lot of buttons" with his critique of industrial-quality lisp usage! I had wanted to reply to them -- point by point -- as to what the various vendors are doing, and to outline why, in theory, these problems are solvable. But many of you folks have already beaten me to the punch on this. And besides, _I_ might appear to be biased to the point of propangandizing for Lucid's particular delivery solutions. Instead, I want to explore a point that is orthogonal to the usual "bull session discussions" that proffer potential technical solutions to these real-or-imagined technical bottlenecks. One thing you said is most interesting: 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. . . . This may provide some insight into the spate of judgements, rendered during the past couple of years, against Lisp and towards C. For example, what Walter says can often be directly verified; e.g., "...the language [Lisp] is sufficiently remote from the machine that it is not always easy to understand the efficiency tradeoffs of using different constructs." This is true even when his main sub-point is trivially refutable -- i.e.: "LISP code is *** always *** significantly slower than C code . . ." [my emphasis added]. Similary, he claims Lisp is a "Memory hog" -- a point which can more or less be conceded -- yet he also claims: "The base development image for Sun Common LISP takes 14 MB!" despite the fact that Sun Common Lisp's so-called base image takes only about 6.5MB on disk (maybe he was referring to his developmental "base", which might include a humongous amount of optional software? and he didn't comment at all about the working-set size, which is of infinite more importance than the requisite virtual memory size.) I can also appreciate his comment about the cultural isolation of the world of Lisp programmers. But what Walter DIDN'T touch upon at all is the really hard part -- the part that usually cannot be easily verified, and the part that makes your remark about the "LISP in C" clothing so cogent. One usually cannot tell just what effect the Lisp "defects" have on the marketability of a winning product. So what! if some stellar, cost-saving application runs 15% slower when delivered in Lisp than would be _theoretically_ possible if delivered in C; or even 50% slower! [Why, the Lisp-to-C conversion cost itself could be on the order of hundreds of thousands of dollars; how expensive do CPU cycles have to be to amortize that kind of development cost?] So what! if one needs 16MB or more of real memory, rather than the paltry 8MB or 12MB common to the low-end workstations, when the software product itself costs well in excess of even a high-end workstation? And with commercial prices for SparcStation memory hovering around $50/MB, the incremental cost here is less than the total cost for the workstation's CRT monitor! The critical observation is -- It's a lot easier to document the micro- benchmark technical issues of an OS, or a Computer Language, one is using than to analyze, even in hindsight, the true contribution to software product success due to one's choice of programming methodology, programming language, or programming tools. Indeed, there may be marketing advantages to dress up the old Lisp wolf in the C Sheep's clothing (such as by pushing a ProKappa over a Lisp-based KEE.) Or, perhaps, it simply is time to admit that no matter how easy and fun it was to code up the product in Lisp, it really didn't didn't take advantage of Lisp's features -- e.g., do we really need a Lotus-1-2-3 clone written in Lisp? (by the way, I certainly don't consider KEE in this category.) And there may even be a hint of technological obsolescence in some products regardless of the language upon which they are built, which could happen for any product that has been essentially riding the AI bandwagon. However, the new re-packaging gives an opportunity to sell new hopes and dreams. The consumers of software, like so many consumers in so many other markets, are too frequently in the business of buying "hopes and dreams" as much as of buying secure, certified solutions. Mike Thome's comparative figures, for Lisp-comparable functionality when stacked up in the "C/Unix world", tend to show that the speed/size arguments really are a murky question; and they can just as easily be used for scapeGoating as for the technological prelude to some Wolf-and-Sheep games. -- JonL --