jjacobs@well.UUCP (Jeffrey Jacobs) (12/21/87)
As long as we are on the subjects of "being informed", "commercial viability" and Dick Gabriel, let me strongly recommend the August 1987 issue of UNIX Review, particularly the (mutual) interview between Earl Sacerdoti (VP at Teknowledge) and Dick (President & Chief Technical Officer of Lucid). (The issue is also noteworthy for two titles mentioned on the cover that *don't* appear in the magazine, "Products that Work" and "Preparations for an AI Winter"). Some quotes: D.G.: "Common LISP just was never designed to be a commercially viable LISP. It was intended to serve as a compromise between the manufacturers of LISP machines and other vendors of LISP products. Never did we think of it as an industrial strength system... So, to the extent that ANSI's ongoing efforts to standardize on Common LISP exercise some influence over how LISP is accepted in the world at large, I anticipate a disaster". E.S.: "Unless we distinguish between the versions of LISP that we intend to use for exploratory research and those that have been designed for commercial use, ANSI's standard is going to end up being a research's standard. Then, if everybody jumps on the bandwagon ot support that as a *commercial* standard, I'd have to say we're setting ourselves up for some serious disappointments.: D.G.: "I think you're absolutely right. But it may already be too late to do anything about it". It is too late. Dick (and others) seemed to think that they could break CL off as a dialect, preserving, as he put it, the name "LISP" for a future language. I also told him that I didn't think it was possible. There are too many people with vested interests, emotional and financial, pushing to have CL as a widely accepted standard (and the emotional interest is stronger than the financial). LISP in America will become Common LISP. Personally, I don't really care whether some (large) portion of the LISP community wants to saddle themselve with CL, but the drive to make it a standard ensures that it will remain a researcher's language. LISP will not go into space; it will not be used to develop commercial software, it will probably not be used to develop much of anything other than editors and extensions to itself. (And it will never achieve the acceptance or widespread use that FORTRAN enjoys). 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
baldwin@cs.rochester.edu (Douglas Baldwin) (12/23/87)
Forward into the inferno! - after all, it's cold here in Rochester this time of year. I don't think there's necessarily anything wrong with a language that is "just" for the research community. As part of that community, I see my job NOT as developing commercially viable things, but as devising and proving concepts that OTHER people can make commerically viable. If I'm lucky and good at what I do then some day maybe my work will revolutionize computing as a whole, but if it does it will be because I had some ideas that somebody ELSE pushed into practical use, and that's how it should be. I think there are a number of examples of ideas that have evolved in more or less this way - expert systems, Pascal, RISC architectures, etc. In any case though, the research world and the "commercial success" world are very different, and have very different needs - specifically, when I write programs I want them to convincingly demonstrate that my ideas are sound, but I don't want to spend time on code that doesn't contribute to this demonstration. This usually means that I don't worry too much about user interfaces, robustness and error handling, time or space efficiency (once the code is efficient enough to produce convincing output at all), etc. I have used Lisp exclusively as my research programming language for something like 4 or 5 years now (for high-performance compilers, incidentally), including even Common Lisp for the last 2 or 3 years. The reason is that Lisp does lots of things for me like storage management, encoding of symbolic data, flexible data typing, etc. that in other languages would be time sinks. (I remember writing a C program after a couple of years of Lisp programming and being shocked that I'd never before noticed how much coding and debugging time went into proper use of "malloc" and "free".) Common Lisp is bigger and uglier than I would like it to be, but if that is the price for getting it supported on a variety of machines then it's worth it (I certainly don't want to put time into debugging my programming language or doing messy ports and multi-machine maintenance every time our lab upgrades). I know full well that all the nice things that Lisp does for me cost efficiency 'though, and I wouldn't expect a commercial developer to have the cavalier attitude towards efficiency that I do - after all, his (or her) priorities are different - he (or she) KNOWS the idea is sound (I've shown that); now they need to show that it can make money. Given the differences between researchers and commercializers, it seems like a good idea for the two groups to use different tools, including different programming languages - as long as the commercializers realize that I'm giving them proven technical ideas but not instant products, and I realize that I'm not going to get the financial rewards from my prototypes that I'd get from a real product, everyone should stay happy. If Common Lisp (or any other Lisp) achieves enough commercial success that the research community can rely on it being supported by vendors and available on a decent variety of machines, then it will be filling an important need. There is no reason to judge the success of a language by how whole-heartedly the entire world embraces it, or to evaluate the quality of the language in terms of how likely it is to have that sort of success.