Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site well.UUCP Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!hplabs!well!jjacobs From: jjacobs@well.UUCP (Jeffrey Jacobs) Newsgroups: net.lang.lisp Subject: Against the Tide of Common LISP Message-ID: <1311@well.UUCP> Date: Fri, 20-Jun-86 01:38:31 EDT Article-I.D.: well.1311 Posted: Fri Jun 20 01:38:31 1986 Date-Received: Sat, 21-Jun-86 13:32:40 EDT Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs) Distribution: net Organization: CONSART Systems Inc., Manhattan Beach CA Lines: 125 Summary: Flame against 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." 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... It is obviously intended to be a "compilable" 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... 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. 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... ______________________________________________________________ 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). 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... 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 ...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 reference? "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). 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? 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. 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