chan@hpfcmp.HP.COM (Chan Benson) (12/15/87)
> Somehow Unix is more flexible and adaptable than Fortran, > even though it is just about as widespread and just about as standardized. Just about as widespread?!... Gimme a break. -- Chan
jjacobs@well.UUCP (Jeffrey Jacobs) (12/15/87)
>In article <332@siemens.UUCP>, steve@siemens.UUCP (Steve Clark) writes: >> ... Will Common Lisp be the Fortran of Lisp? >No, CommonLisp is more like the Ada of Lisps. A standardized committee >effort, designed to include everything including the kitchen sink. I have to disagree; Common LISP is the PL/I of Lisps. Too big and too incomprehensible, with no examiniation of the real world of software engineering. ADA, while it has is problems, is a very well though out, well constructed language. The process that resulted in ADA and the process that resulted in Common LISP are worlds apart, the only similarity is the use of the term "committee". The CL effort resembles a bunch of spoiled children, each insisting "include my feature or I'll pull out, and then we'll all go down the tubes". Everybody had vested interests, both financial and emotional. CL is a nightmare; it has effectively killed LISP development in this country. It is not commercially viable and has virtually no future outside of the traditional academic/defense/research arena. It should be embarassing to everybody in the field that most shells and tools are no longer written in LISP. To quote Dick Gabriel, the "father of Common LISP": "Common Lisp is a significantly ugly language. If Guy and I had been locked in a room, you can bet it wouldn't have turned out like that" - WESTEX 86 (or maybe 85). Dick has also stated that the attempt to make Common LISP a commercial standard is a disaster. (One must in fairness point out that a father is not totally responsible for his offsprings behaviour). ADA, despite it's problems, is o well thought out, engineered language. Any comparision with CL is odious; but comparing CL to PL/I, that incredibly ancient monster, is perfect... 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
skef@SPICE.CS.CMU.EDU (Skef Wholey) (12/16/87)
Well, I see it's time for JJJJacob's semi-annual Common Lisp flame. Rob did a good job with this guy last time, but is sitting this round out. I'll take a turn at it, not because I believe that a person this far gone can be straightened out, or because I'm afraid his ignorance is contagious, but because I'm collecting some memory-usage statistics on this Lisp-based text editor I'm using, and I need the keystrokes... >In <4732@well.UUCP>, jjacobs@well.UUCP (Jeffrey Jacobs) writes: >I have to disagree; Common LISP is the PL/I of Lisps. Too big and >too incomprehensible, with no examiniation of the real world of >software engineering. Incomprehensibility, like boredom, usually springs from a deficiency in the beholder rather than the beheld. >It should >be embarassing to everybody in the field that most shells and tools are >no longer written in LISP. I assume that by "the field" he means AI, and that by "shells" he means expert system shells and the like. The reason a lot of applied AI and expert systems work is being done in other languages has little to do with Common Lisp. The development of Common Lisp was coincident with a lot of work that pinned down just how one should go about implementing rule-based systems, effectively removing such systems from the arena of exploratory programming. Exploratory programming is what Lisp is all about -- it also happens to be what a lot of AI is about: that's why they've existed side by side for so long. But neither has any hard ties to the other. You can do AI in C, and you can write window systems in Lisp. When the cost of such things as software maintenance and delivery vehicles for "AI" systems is important, C can often beat Lisp hands down. Any Lisp. There are far more C hackers and C compilers out there than there are Lispers and Lisps, and I doubt that this will ever change. However, the latter numbers have grown by leaps and bounds since the introduction of Common Lisp. >To quote Dick Gabriel, the "father of Common LISP": Funny that he goes on to quote a man who is profiting from the commercial viability that, earlier, he asserts doesn't exist. Also, Gabriel is "a father" of CL, not "the father." Every one of the five principal designers will tell you he could have designed a better language by himself, or with one or two of the others, and many were trying to do just that when the standards effort began. If all had proceeded undisturbed, there might be several beautiful Lisps by now, but they would be largely incompatible, and each would run only on one or a few machines. Probably none would be supported by any large computer manufacturers. Common Lisp is not perfect. The problem with perfection is that different people have different ideas of what it is. When you put a group of smart, experienced people together and tell them to create something, you'll usually end up with a compromise. If you're lucky (and I believe in the case of Common Lisp we were lucky), that compromise will not be so bad. I imagine that JJacobs wasn't around when the initial design of Common Lisp was going on over the ARPAnet, and I'm sure he wasn't at either of the two face-to-face meetings. I'll bet that he hasn't even read any of the old Common Lisp mailing list archives, in which much of the rationale for various design points of Common Lisp can be found. Sorry, JJacobs, but you're just not very well informed. >ADA, despite it's problems, is o well thought out, engineered language. >Any comparision with CL is odious; but comparing CL to PL/I, that incredibly >ancient monster, is perfect... When one stretches a metaphor hard it often becomes limp and useless (that's a meta-metaphor!). The more one tries to draw from these comparisons the less meaningful they become. I suppose I could say, "Jeffrey M. Jacobs is the punched card of the comp.lang.lisp community," but I would risk the possibility that someone might find something nice to say about punched cards. -- Skef Wholey (Wholey@C.CS.CMU.EDU)
hedrick@athos.rutgers.edu (Charles Hedrick) (12/18/87)
>I imagine that JJacobs wasn't around when the initial design of Common >Lisp was going on over the ARPAnet, and I'm sure he wasn't at either of >the two face-to-face meetings. I'll bet that he hasn't even read any Well, I was around. I participated in the distributed committee, including the votes, and I was at one of the meetings. I believe JJacobs' description of the process has a certain basis in fact, but that the result was inevitable given the goals that CL was intended to meet. It is true that many people suggested features. On a number of occasions I tried to get people to simplify the language, and found that it was *much* easier to get a feature added than to get one removed. I was a voice crying in the wilderness, aided only by the folks at Utah now and then. Like Jacobs, I also heard comments in private suggesting that threats of withdrawl from the project had been used to keep features in the language. Knowing this sort of thing, I doubt that there were really any overt threats, just signs that people whose influence was crucial to the project would likely become much less enthusiastic if the language wasn't a reasonably large subset of LM Lisp. Despite all of these things, I think the image of CL as a union of features drawn from a bunch of random users is simply not right. It was intended from the start to begin with existing dialects of Maclisp, including Lisp Machine Lisp, and to provide something that was sort of like an intersection, but cleaned up and made consistent. It is in fact reasonably consistent. The main design issue was how close it should be to LM lisp in size. I believed (and still believe) that LM lisp is a monster, and that CL should not use it as a model. However LM lisp was very influential within the Maclisp community at the time, and after all CL was supposed to represent the concensus of the Maclisp community as to what a base Lisp should look like. In this context, it was perfectly reasonable for people to have believed that the language should be on the same scale as LM Lisp, and one need not imply that nefarious motivations were involved. I happen to think that they were wrong. I'd like to see a Lisp which is practical to use for things other than large AI programs running on huge machines. I am simply offended by a language of this size. But CL did achieve its goal, and it's not clear that reducing the number of people involved in its design would have made it much smaller. As long as there was a concensus among the Maclisp community that they wanted a substantial subset of LM Lisp, the result was bound to have been on the same scale as CL. From the beginning, almost all of the community involved in the design wanted a big lisp. It didn't get there feature by feature, with people stepping back in shock when they saw how it ended up. There were explicit discussions about size, and people said that they would rather have all the functions that are commonly used present, so people didn't constantly have to reinvent them. Guy may have been picked because he had previously designed a small, elegant, Lisp, but he was given the job of coordinating the design of a big Lisp.
bzs@bu-cs.BU.EDU (Barry Shein) (12/27/87)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) I've had my misgivings about CL, and there are certainly dubious features I would have thrown out the window (the most dubious of which is probably multiple-value-returns, there simply to support some machines with a little fast stack hardware, I mean really, why not just return a list even if it's faked onto the stack?) but I find it useful nonetheless. I mean, car is car and all that. In fact, it's not the "bigness" that's the problem. The perceived bigness is mostly due to the minutiae it deals with (most of which is reasonably useful.) Rip everything out of the CL book that you didn't need to read and I think you won't find a whole lot left (assuming you've been around the community, that's not a criticism by the way.) The problem is how little it standardized, that's where I think the final evaluation of CL will find its criticisms. The fact that it doesn't cover things like fonts, windows, networking primitives (well, sort of), object-oriented interfaces, real operating system environment details (eg. a mandated file system view rather than "oh, it'll take whatever string the host system does"), debuggers and other development tools etc etc is the problem. Without dealing with these issues one ends up with a relatively non-portable language because all these things end up in programs anyhow and just create problems. The lack of devpt environment details of course impacts the portability and standardization of people. Swell, now we got Lucid/Sun hackers who would probably be totally lost on a lisp machine CL. Now, I'd be the first to admit that getting all that right would have been hard and a lot of work (no one said claiming to have standardized LISP was supposed to *easy*), but I think it was critical to its possibility of finding any large-scale commercial success. The problem was that too many people were thinking in terms of some least-common denominator, they should have subsetted that perhaps. I have little doubt that the conversations between the DEC/VMS folks and the Lisp Machine community (LMI, Symbolics, Xerox) must have been amusing at best (fonts?! no fonts no way, heck, we don't even want lower case!!) It really was a case of a standardization of a language within a least-common denominator view as it existed some time in the late 70's on largish dumb-terminal oriented time-sharing systems. That's too bad but it's not surprising, such people tend to have had their 10+ years under their belts and got their way via seniority, so we got a standard that looks real compatible with a DEC-10 just as the last one rolled off the line...I guess standards have a way of looking backwards only. It would be nice to hear that people consider the possibility of a Common Lisp '90 or some such is open to discussion. Perhaps there's still a chance to make it a viable language and reflect modern needs. -Barry Shein, Boston University
shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (01/21/88)
Good old jjacobs is flaming again! RAM has bowed out on this one, but I have a few spare moments to counterflame... In article <4732@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: >ADA, while it has is problems, is a very well though out, well constructed >language. The process that resulted in ADA and the process that resulted >in Common LISP are worlds apart, the only similarity is the use of the >term "committee". Jacobs must be angling for DoD money or something. I don't think I've ever heard anybody, not in the pay of the DoD, say anything good about Ada... Tony Hoare's Turing lecture certainly had some critical remarks, to the effect that we risk missiles hitting our own cities by using Ada. (I don't know what he thinks about CL.) The process resulting in Ada had the advantage of a sponsor deciding in advance that it was going to be successful (the DoD *never* has failures, of course!), while the CL folks had to design the language for acceptability to an uncoercable community, and it was not at all certain whether it would be successful. I would say that its success over many competitors is an indication that, by and large, CL is a pretty good language. CL has also been victimized by rising expectations; years ago it was criticized for being too radical and too ambitious, for instance by adopting lexical scoping as the default. Now lexical scoping seems to be taken for granted, and CL is criticized for allowing dynamic variables... >CL is a nightmare; it has effectively killed LISP development in this >country. You're going to need some facts to back up that assertion. I see plenty of Lisp work going on. >It is not commercially viable and has virtually no future >outside of the traditional academic/defense/research arena. People outside this arena don't generally have any interest at all in higher-level languages. There are *no* successful general-purpose languages above the level of C/Pascal/Ada (4GLs are fairly specialized). CL in fact has the best shot at success, but it needs some good cheap implementations. >It should >be embarassing to everybody in the field that most shells and tools are >no longer written in LISP. It *is* embarassing, but CL is not the reason; the same thing would have happened if (for instance) Scheme had been standardized on. I place the blame on lazy and timid Lisp implementors who forgo optimizations because "they would compromise Lisp tradition", and companies who get away with selling shoddy systems because there is little or no competitition. >To quote Dick Gabriel, the "father of Common LISP": > >"Common Lisp is a significantly ugly language. If Guy and I had been locked >in a room, you can bet it wouldn't have turned out like that" - WESTEX 86 >(or maybe 85). Yeah, it would have looked like APL, been partially implemented once, and ended up on the giant dustheap of forgotten languages. 1/2 :-) To take another quote from Gabriel, this time from the 1984 Lisp conf: "... the world is better off having a Common Lisp than not." I seem to remember that last year or the year before or sometime, Jacobs was hinting at a fantastic new Lisp dialect that was going to supplant Common Lisp and presumably start a revolution in computing... wonder whatever happened to it? stan shebs shebs@cs.utah.edu
fritz@hpfclp.HP.COM (Gary Fritz) (01/27/88)
Stan Shebs writes: > Tony Hoare's Turing lecture certainly had some critical remarks, to the > effect that we risk missiles hitting our own cities by using Ada. > (I don't know what he thinks about CL.) Hoare's lecture should be required reading for all computer scientists. The passage Stan refers to is: "...I appeal to you, representatives of the programming profession in the United States, and citizens concerned with the welfare and safety of your own country and of mankind: do not allow this language [Ada] in its present state to be used in applications where reliability is crucial, i.e. nuclear power stations, cruise missiles, early warning systems, anti-ballistic missile defense systems. The next rocket to go astray as a result of a programming language error may not be an exploratory space rocket on a harmless trip to Venus. [*] It may be a nuclear warhead exploding over one of our own cities." [*] Refers to a Mariner Venus probe reportedly lost because of the lack of compulsory declarations in FORTRAN Judging by his comments on ALGOL 60, ALGOL 68, PL/I and Ada, I would guess that Hoare is probably not an ardent fan of Common Lisp. Hoare's lecture can be found in the September 1981 issue of BYTE, pp 414ff, and I imagine in CACM around the same time. Gary Fritz