jjacobs@well.UUCP (Jeffrey Jacobs) (12/27/87)
Skef Wholey (no "r") writes: >Common Lisp was a comprimise, and it looks that way. I freely admit >that. The same can be said of the US constitution (Electoral college? >What a silly way to elect a President!) and the US government in >general. Munich, Yalta and the Paris Peace Accords (Vietnam) were also compromises! Compromise is seldom good or bad by itself; it is the result that is important. (And Common Lisp is hardly the U.S. Constitution). >This, as I argued before, is more a result of the development of >low-cost high-performance "stock" hardware (e.g. Sun-4) than the >development of Common Lisp. Wish I could agree, but I can't. LMI was doomed from the beginning; you can't survive by saying that you are only going build faster, more expensive hardware, and to heck with price/market considerations. The sales of Lisp for workstations is not that great; I would estimate a combined sales by Lucid and Franz' Allegro at less than 4,000 copies, which is roughly equal to total Symbolics sales. Over a period of several years. The problem is simply lack of demand! And your argument has nothing to do with the problems that Inference, Carnegie, Intellicorp and Teknowledge are having. >The Common Lisp designers were foresighted >enough to design the language so that implementations on such stock >hardware could be reasonably efficient. Gee, I hate to get back into character assasination, but this is pure bogus B.S. Perhaps we have different views of what constitutes "stock hardware". If you micro-code it for Lisp, it's not stock. Stock consists of VAX, 680x0, INTEL 80x8x, Gould, Prime, WE 3200, etc. I would certainly like to see any evidence that you can produce that shows that any consideration was given to stock hardware. Gabriel & Brooks "A Critique..." certainly says otherwise, as does my own reading and interpretation. In the past 4 years of flaming, nobody, but nobody has ever advanced this argument. In fact, many people have argued just the opposite, that Common Lisp is not intended to be run on stock hardware. In fact, you effectively contradict this by saying: >Small computers are getting bigger all the time, and becoming more >capable of running Common Lisp. How about this: Common Lisp is not a >car (or a cdr!), it is a track to be run. Now if you substitue "track" with obstacle course, then we can agree <grin>. Any idiot can design software that will won't perform well; it happens all the time. A good part of our business has always been fixing performance problems. > Small machines are getting to >the point where they can run this track fast enough to make them >competitive. So what? This is 1987, nearly 1988. CL was basically designed in 1982. The world isn't really interested in waiting for the day that small machines are good enough to be competitive. CL simply isn't desired by the world at large. (And what do you mean by "small"; Mac II with 4 meg, uVax, $36K Symbolics, Intel 80386 with 8 meg?) This problem has been around longer than I have. There always seems to be a belief that Lisp must always be ahead of the capabilities of the current generation of hardware. But Lisp does not and has not influenced mainstream hardware development. Hardware tagging and type checking are not to be found outside of the Lisp machine world (unless you microcode it yourself, in which case it's not "stock"). Think of the possibilities if a standard Lisp could run on current architectures; instead of everybody sitting around waiting to be able to do things when the hardware catches up, things would be progressing, and the next generation of hardware would expand the number of things that could be done, and improve the things we would be have available now! >Well, gosh, I was away from CMU for fourteen months (on a leave of >absence from grad school) working as a High Paid Lisp Wizard in Cambridge... One well known Lisp developer's leave of absence does not a high demand for Common Lisp make. (In fact, we can make a case that one of the reasons Common Lisp is so big and complex is to keep the supply of Lisp programmers small so that the few around are sure to find jobs <grin>). >Then the commercial world won't have to worry about it, and they can >develop something better. Right? Wrong! The commercial world has always believed that Lisp is too big and too slow for commercial use and are not about to put any money into Lisp R&D. In fact, I will go so far as to predict that the majority of commercial implementation by hardware vendors will never be Steele complete, and that in general the performance and resources required will be such that their Common Lisps will simply languish in the catalogue, with very few users. >And large programs have been >ported from their experimental Lisp form into a "productized" C form. I >was involved with such a port myself. Not too terrible if you've got >the right tools, and/or write some of the code with that port in mind. Riiiiight! Ask Inference and Carnegie about it <grin>. But in the real world, this is generally an unacceptable approach. "Gee, Mr. Boss, we'll spend six months to year doing it in Lisp; then we'll take another year to rewrite it in C, then we'll fix any lingering performance problems". This approach has turned off more potential users of Lisp and AI technology than anything else. (BTW, I am *not* a big C fan). Finally, THERE IS NO REASON THAT WE CAN'T HAVE A LISP THAT WILL ULTIMATELY PRODUCED EFFICIENT, GOOD RUNTIME CODE!!! Lisp, more than any other language, had the potential to provide a development environment that would provide the user with an unmatch path from experimentation to highly polished end product. Common Lisp killed this potential by becoming just another programming language, sort of a Pascal with parentheses. Re Lisp in Space; I'm not referring to SDI. One of John Seely Brown's earliest inspirations lectures had to do with the problems of robots and artificial intelligence exploring the planets. FYI, most space born software is written in Jovial, not assembly. Future work is to be in ADA. Merry Christmas! Jeffrey M. Jacobs CONSART Systems Inc. Technical and Managerial Consultants P.O. Box 3016, Manhattan Beach, CA 90266 (213)376-3802 CIS:75076,2603 BIX:jeffjacobs USENET: jjacobs@well.UUCP
mincy@think.COM (Jeffrey Mincy) (12/27/87)
In article <4851@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: >Skef Wholey (no "r") writes: >>The Common Lisp designers were foresighted >>enough to design the language so that implementations on such stock >>hardware could be reasonably efficient. >Gee, I hate to get back into character assasination, but this is pure bogus B.S. Actually, it is not bogus. >Perhaps we have different views of what constitutes "stock hardware". If >you micro-code it for Lisp, it's not stock. Stock consists of VAX, 680x0, INTEL >80x8x, Gould, Prime, WE 3200, etc. No, skef understands what "stock hardware" is. >I would certainly like to see any evidence that you can produce that shows that >any consideration was given to stock hardware. Gabriel & Brooks "A Critique..." >certainly says otherwise, as does my own reading and interpretation. There is nothing in common lisp that can not be implemented efficiently. It is only a matter of programming, and understanding. The only thing that common lisp (any lisp for that matter) requires that stock hardware does not have is type tags. A few other things like microcode for doing cdr-coded lists, and pointer chasing for incremented gc's are nice, but not neccessary. I used to work at data general (maker of the "stock hardware" MV series), where I worked in the common lisp group. I have thought about these issues. I'll be more than happy to talk about individual features of common lisp, and how they can be implemented efficiently on stock hardware. > Jeffrey M. Jacobs -- jeff seismo!godot.think.com!mincy
lou@aramis.rutgers.edu (Lou Steinberg) (12/28/87)
In article <4851@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: > [...] But Lisp does not and has not influenced mainstream hardware > development. Do you consider the DEC-10 (and DEC-20) architecture mainstream? How about the SPARC (Sun-4) architecture? Both were explicitly designed to be good at both Fortran and Lisp. (Of course, ideas about what was "good for lisp" have evolved some in between those two examples.) In particular, despite your claim that > Hardware tagging and type checking are not to be found outside > of the Lisp machine world the SPARC architecture does indeed have some hardware type tagging and checking. -- Lou Steinberg uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou arpa: lou@aramis.rutgers.edu
jh@tut.fi (Juha Hein{nen) (12/28/87)
In article <4851@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: >end product. Common Lisp killed this potential by becoming just another >programming language, sort of a Pascal with parentheses. Wirth probably don't like your comparison. Considering its size, Common Lisp would better relate to Ada. Why this argument about Common Lisp? Lisp doesn't live or die with Common Lisp or is someone forcing it at you? We have been using Scheme for more that a year and are extremely happy with it: no problems with size or complexity. -- Juha Heinanen Tampere Univ. of Technology Finland jh@tut.fi (Internet), tut!jh (UUCP)
oz@yunexus.UUCP (Ozan Yigit) (01/02/88)
In article <2248@korppi.tut.fi> jh@tut.fi (Juha Hein{nen) writes: >Why this argument about Common Lisp? Lisp doesn't live or die with >Common Lisp or is someone forcing it at you? We have been using >Scheme for more that a year and are extremely happy with it: no >problems with size or complexity. Right. I am looking forward to the day the name "lisp" and "scheme" will be synonymous, and all others will be referred as, uhm, others. CL will be fondly remembered as the dinosaur that made "scheme" the true Lisp. happy scheming. oz -- Those who lose the sight Usenet: [decvax|ihnp4]!utzoo!yunexus!oz of what is really important ......!seismo!mnetor!yunexus!oz are destined to become Bitnet: oz@[yusol|yulibra|yuyetti] irrelevant. - anon Phonet: +1 416 736-5257 x 3976