Path: utzoo!mnetor!uunet!oddjob!uwvax!dogie!uwmcsd1!bbn!rochester!baldwin From: baldwin@cs.rochester.edu (Douglas Baldwin) Newsgroups: comp.lang.lisp Subject: Re: Commercial Viability Message-ID: <5480@sol.ARPA> Date: 22 Dec 87 16:48:33 GMT References: <4792@well.UUCP> Sender: news@cs.rochester.edu Reply-To: baldwin@cs.rochester.edu (Douglas Baldwin) Distribution: comp.lang.lisp,comp.ai Organization: U of Rochester, CS Dept, Rochester, NY Lines: 68 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.