Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!brl-adm!seismo!rpics!yerazuws From: yerazuws@rpics.UUCP Newsgroups: comp.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <768@rpics.RPI.EDU> Date: Sun, 8-Feb-87 11:14:15 EST Article-I.D.: rpics.768 Posted: Sun Feb 8 11:14:15 1987 Date-Received: Mon, 9-Feb-87 04:46:41 EST References: <2545@well.UUCP/ Lines: 226 Keywords: Flame Repeat Original Common LISP Tide Summary: It's really not that bad at all... (slightly longish) In article <2545@well.UUCP/, jjacobs@well.UUCP (Jeffrey Jacobs) writes: / / "Against the Tide of Common LISP" / / Copyright (c) 1986, Jeffrey M. Jacobs, CONSART Systems Inc., / P.O. Box 3016, Manhattan Beach, CA 90266 (213)376-3802 / Bix ID: jeffjacobs, CIS Userid 75076,2603 / / Reproduction by electronic means is permitted, provided that it is not / for commercial gain, and that this copyright notice remains intact." Do I really need to keep that there? :-) / / The following are from various correspondences and notes on Common LISP: / / Since you were brave enough to ask about Common Lisp, sit down for my answer: / / I think CL is the WORST thing that could possibly happen to LISP. In fact, I / consider it a language different from "true" LISP. CL has everything in the / world in it, usually in 3 different forms and 4 different flavors, with 6 / different options. I think the only thing they left out was FEXPRs... Sorry, no. Flavors are not part of the CL definition. You can add them yourself if you want. :-) / It is obviously intended to be a "compileable" language, not an interpreted / language. By nature it will be very slow; somebody would have to spend quite a / bit of time and $ to make a "fast" interpreted version (say for a VAX). The / grotesque complexity and plethora of data types presents incredible problems to / the developer; it was several years before Golden Hill had lexical scoping, / and NIL from MIT DOES NOT HAVE A GARBAGE COLLECTOR!!!! / It just eventually eats up it's entire VAX/VMS virtual memory and dies... Agreed- but garbage collectors are no fun to write. The DEC product GC's a full three megabytes in less than ten seconds- provided you have enough physical memory. Not my (or CL's) fault if someone decides not to complete the implementation. / / Further, there are inconsistencies and flat out errors in the book. So many / things are left vague, poorly defined and "to the developer". / / The entire INTERLISP arena is left out of the range of compatability. True - there is no "spaghetti stack". But I've never really found a good use for such a stack. I've never had to deal with a problem that sat up and said to me "Hey, dummy, use the spaghetti stack!" / / As a last shot; most of the fancy Expert Systems (KEE, ART) are implemented in / Common LISP. Once again we hear that LISP is "too slow" for such things, when / a large part of it is the use of Common LISP as opposed to a "faster" form / (i.e. such as with shallow dynamic binding and simpler LAMBDA variables; they / should have left the &aux, etc as macros). Every operation in CL is very / expensive in terms of CPU... / That depends on what model you use to interpret/compile your lisp source into. There's no reason why your compiler/interpreter can't remember what few variables are lexically scoped and handle them accordingly, keeping the rest shallowly-bound in hash-table with a fixup stack. / / ______________________________________________________________ / / I forgot to leave out the fact that I do NOT like lexical scoping in LISP; to / allow both dynamic and lexical makes the performance even worse. To me, / lexical scoping was and should be a compiler OPTIMIZATION, not an inherent / part of the language semantics. I can accept SCHEME, where you always know / that it's lexical, but CL could drive you crazy (especially if you were / testing/debugging other people's code). The rule I use is simple - if it appears in the argument list, it's lexical. If not, it's dynamic. Then just look for PROGV's and that tells you whether it's a binding that will get undone someday or if it is a global. I also ignore all the warnings from the compiler "Foo has been assumed special". (to the extent that I worry only that I didn't blow it and write "foo" when I meant "foobar") / / This whole phenomenon is called "Techno-dazzle"; i.e. look at what a super / duper complex system that will do everything I can build. Who cares if it's / incredibly difficult and costly to build and understand, and that most of the / features will only get used because "they are there", driving up the cpu useage / and making the whole development process more costly... / Well, I can say that the features concerning general sequences are something I've had to kludge for myself in most other lisps, and I am very glad to see them in CL. They make writing an optimizing compiler much easier (that is, writing an optimizing compiler IN lisp, not necessarily FOR lisp) So what if they're only macros? The save me the trouble of having to write such a thing myself, they are probably tested better than I would bother to test my own creations, and maybe they're even somewhat optimized (Hi Walter and Paul! :-) ). I admit, when I sit down to do something truly bizarre, I do need a copy of the book with me- but I really can write cleaner (that is, more understandable and easier-to-test-and-debug) code if I use the built-ins. / BTW, I think the book is poorly written and assume a great deal of knowledge / about LISP and MACLISP in particular. I wouldn't give it to ANYBODY to learn / LISP / True. Franz Opus 36 is better for people starting out. / ...Not only does he assume you know a lot about LISP, he assume you know a LOT / about half the other existing implementations to boot. / / I am inclined to doubt that it is possible to write a good introductory text on / Common LISP; you d**n near need to understand ALL of it before you can start / to use it. There is nowhere near the basic underlying set of primitives (or / philosophy) to start with, as there is in Real LISP (RL vs CL). You'll notice / that there is almost NO defining of functions using LISP in the Steele book. / Yet one of the best things about Real LISP is the precise definition of a / function! / / Even when using Common LISP (NIL), I deliberately use a subset. I'm always / amazed when I pick up the book; I always find something that makes me curse. / Friday I was in a bookstore and saw a new LISP book ("Looking at LISP", I / think, the author's name escapes me). The author uses SETF instead of SETQ, / stating that SETF will eventually replace SETQ and SET (!!). Thinking that / this was an error, I checked in Steel; lo and behold, tis true (sort of). / In 2 2/3 pages devoted to SETF, there is // 1 << line at the very bottom / of page 94! And it isn't even clear; if the variable is lexically bound AND / dynamically bound, which gets changed (or is it BOTH)? Who knows? / Where is the definitive reference? / Yeah, I ignore SETF pretty much unless I'm making an array reference. Then I pretend I'm typing AREF and then fix the syntax. / "For consistency, it is legal to write (SETF)"; (a) in my book, that should be / an error, (b) if it's not an error, why isn't there a definition using the / approprate & keywords? Consistency? Generating an "insufficient args" / error seems more consistent to me... / / Care to explain this to a "beginner"? Not to mention that SETF is a / MACRO, by definition, which will always take longer to evaluate. / / Then try explaining why SET only affects dynamic bindings (a most glaring / error, in my opinion). Again, how many years of training, understanding / and textbooks are suddenly rendered obsolete? How many books say / (SETQ X Y) is a convenient form of (SET (QUOTE X) Y)? Probably all / but two... / / Then try to introduce them to DEFVAR, which may or may not get / evaluated who knows when! (And which aren't implemented correctly / very often, e.g. Franz Common and Golden Hill). Why bother DEFVARing? It says right in CLTL that it won't affect correctness, just efficiency. / / I don't think you can get 40% of the points in 4 readings! I'm constantly / amazed at what I find in there, and it's always the opposite of Real LISP! / / MEMBER is a perfect example. I complained to David Betz (XLISP) that MEMBER / used EQ instead of EQUAL. I only checked about 4 books and manuals (UCILSP, / INTERLISP, IQLISP and a couple of others). David correctly pointed out that / CL defaults to EQ unless you use the keyword syntax. So years of training, / learning and ingrained habit go out the window. How many bugs / will this introduce. MEMQ wasn't good enough? / Different lisp designers have different ideas about where it's right to EQ, EQUAL, etc. Matter of personal taste. / MEMBER isn't the only case... / / While I'm at it, let me pick on the book itself a little. Even though CL / translates lower case to upper case, every instance of LISP names, code, / examples, etc are in **// lower <<** case and lighter type. In fact, / everything that is not descriptive text is in lighter or smaller type. / It's VERY difficult to read just from the point of eye strain; instead of / the names and definitions leaping out to embed themselves in your brain, / you have to squint and strain, producing a nice avoidance response. / Not to mention that you can't skim it worth beans. / True. I wish I could get a copy of CLTL in TeXable form- and then modify the function-font macro to be about 1.2 times the size of descriptive text. / Although it's probably hopeless, I wish more implementors would take a stand / against COMMON LISP; I'm afraid that the challenge of "doing a COMMON LISP" / is more than most would-be implementors can resist. Even I occasionally find / myself thinking "how would I implement that"; fortunately I then ask myself / WHY? / / Jeffrey M. Jacobs