Subject: Re: New CL (Was Re: Lisp per se) From: Erik Naggum <erik@naggum.no> Date: 1997/04/21 Newsgroups: comp.lang.lisp Message-ID: <3070618814395927@naggum.no> * P. Srinivas | CL is now at cross roads. If we miss the chance, it might die, not | because of its weekness as lisp language, but because of our neglect. 20 | years from now somebody will come along and say tghings such as lisp is | not a good language and give the example of CL that would have | disappeared by then. Common Lisp has only recently been standardized. give us all a rest while we're trying to digest the standard, make marginal notes on improvements and ambiguities, form the intelligent questions we need to ask, and let the vendors produce completely conforming Common Lisp implementations that can be _trusted_ for the next 10 years. we're really not in the hurry that plagues the Windows/Intel world. Lisp projects are big enough investments to be affected by climate and standards committees. most of the "modern" stuff out there is small enough to be affected by weather and advertising. the period following a standard's approval is generally one of resignation. a lot of people didn't get what they wanted, while others face the task of building conforming implementations. many very good people will see that their task is done, and leave, exhausted. but businesses need to recover the losses they took while being heavily engaged in the standards actitivy over many years. standardization is like foreign aid -- those who don't engage in it are short-term winners, but those who set the agenda for a developing industry can reap vast profits later. but unlike foreign aid, businesses have definite goals and need to reap those profits before they can go on. please don't deny them that opportunity. a hurried deconstruction of the trust and stability that has been built into the enormous document known as ANSI X3.226 will surely kill Common Lisp. spread uncertainty, and people won't plan on using your improving technology until it has, in fact, improved. (something brand new will be given the benefit of the doubt, but something that works well, but somebody tells you will be improved, doesn't get that benefit.) in times of rapid change, the range of people's planning is reduced from decades to months. please don't inflict that on Common Lisp. (if you don't kill Common Lisp, you will kill all the incentives to produce conforming implementations.) yes, there are things I want to change, too, but I trust that I can work with the vendor of the Lisp I use to get it, and I can code most of it myself if not. maybe in 5 years' time, I'll be able to join a roomful of Lisp experts in ANSI X3J13 and be able to contribute something instead of just being a rebel without a clue. maybe other people will need less time, but my take on the standard is that not even the brilliant people who brought it forward to completion know _exactly_ what it says at this time. having taken part in a standardization process, I know how hard it is to remember the _final_ of the many wordings used in drafts, and with all the context that we carry around when writing, there may be inconsistencies caused by the time of last update, if nothing else. if we hurry this process, we will undo the careful construction of precise meaning that goes into requirements in a standard. ANSI X3.226 is due for a 5-year review in 1999. at the first review of a standard, it is usual to clarify, not change. at the second review of a standard, it usually becomes necessary to make changes. that's 10 years. if a standard is worth having in the first place, 10 years is not a long time for it to live. ANSI X3.159 was approved in 1989. it is facing a serious make-over in ISO these days. the Committee Draft was recently sent out for registration. the standard should be approved and published within two years, if the schedules are met. that's also 10 years. (X3.159 is C.) ANSI X3.159 received an enormous number of requests for clarification in its first few years. I don't know of any requests for clarification to ANSI X3J13. (I asked when I ordered my copy of ANSI X3.226.) as I have argued elsewhere, standardization and evolution should not overlap. if there is significant evolution, a standardization process might kill it or we might standardize prematurely. both are bad. right now, I want most of all to see perfectly conforming implementations built and sold with significant profits by the very good people who produce Common Lisp systems. I want this for two reasons: (1) I want to point to Common Lisp the Standard and say like Guy Steele said in 1990: "Common Lisp has succeeded". if I can't do that, I really can't argue for the success of a pie-in-the-sky _improved_ Common Lisp, either. (2) I want to uncover all the things in Common Lisp that are hard to implement, not used in practice even it is implemented right, either because it's insufficient or because it doesn't address the envisioned problems, I don't think we learn what's right from mistakes, we learn what's wrong, what _not_ to do. if we can't do something right after such an enormous effort like that which went into Common Lisp the Standard, I for one would have very slim hopes of doing it better the next time. after a mistake has been uncovered in a standard or any specification, you wouldn't believe the number of "good ideas" that surface from know-it-alls. all the old rejects crawl out of the woodwork at such a time and some standards aren't improved simply because the editor has to put a cap on the "good ideas". if Common Lisp shall be improved, it must be done by people who think what we have today is _not_ a product of mistakes, but the best that could be done at the time, and they have to understand the reasons why it was the best that could be done. only then can they improve on it with any hope of getting actual improvement, even if it means changing directions somewhat. the biggest problem with this approach is that people who really understand something as big as Common Lisp the Standard are very hard to come by. on a related note, I attempted to post a question on "designators" to comp.std.lisp a couple months ago. I neither heard from the moderator nor saw the article posted nor got any replies. if we wish to discuss renewed standardization of Lisp, I suggest that whoever is in position to revive comp.std.lisp do so. such debates should not go in comp.lang.lisp, and probably not in wide open fora like USENET in the first place. #\Erik -- Bastard Sex Therapist from Hell: "Read the F*cking Manual!"