Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!ut-sally!utah-cs!shebs From: shebs@utah-cs.UUCP (Stanley Shebs) Newsgroups: net.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <3827@utah-cs.UUCP> Date: Fri, 20-Jun-86 21:11:35 EDT Article-I.D.: utah-cs.3827 Posted: Fri Jun 20 21:11:35 1986 Date-Received: Sun, 22-Jun-86 04:00:50 EDT References: <1311@well.UUCP> Reply-To: shebs@utah-cs.UUCP (Stanley Shebs) Distribution: net Organization: University of Utah CS Dept Lines: 335 In article <1311@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: > "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." I don't why I'm bothering to respond to this uninformed flame, but I've got a few minutes to kill before running off to the compiler conference... Besides, somebody might read this and suppose that this Jeff Jacobs knows what he's talking about, which is rarely the case, based on this limited sample. >I think CL is the WORST thing that could possibly happen to LISP. In fact, I >consider it a language different from "true" LISP. Well gee, I wonder what is "true" Lisp... > CL has everything in the >world in it, usually in 3 different forms and 4 different flavors, with 6 >different options. Actually, they decided to omit flavors, because no one could agree on a standard! :-) > I think the only thing they left out was FEXPRs... FEXPRs are bad (see Pitman's paper in the 1980 Lisp conference) >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). So who cares about making interpreted code fast? By the time I get to caring about the speed of a program I'm building, it's generally stable enough that compiling is no big deal. ALL production quality Lisps nowadays are designed to be "compilable" languages. Can't beat the speed of C programs by running interpreted, you know... >The grotesque complexity and plethora of data types Yeah, Common Lisp has just about as many data types as Fortran... >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... So what do broken implementations have to do with the language standard? >Further, there are inconsistencies and flat out errors in the book. So many >things are left vague, poorly defined and "to the developer". It's hard to imagine that a first version of a language standard will be perfect. I hear about oddities in the Ada language standard too. Many of the vaguenesses in the Common Lisp standard are to allow implementations some freedom to do things in different ways. Would you like it if the *language* standard said that the architecture will be tagged, and that positive fixnums range between 0 and 32767, and that they will have a tag of 42? >The entire INTERLISP arena is left out of the range of compatability. Most folks that haven't followed the Common Lisp effort don't realize how monumental a task it was to get all the Maclispers to agree on a language standard. There is simply no way to get a Lisp that is both Maclisp- and Interlisp-compatible. >Every operation in CL is very expensive in terms of CPU... Not in clever implementations... >I forgot to leave out the fact that I do NOT like lexical scoping in LISP; I LIKE lexical scoping in Lisp - dynamic scoping is for special situations, like rebinding a global variable for the duration of a function (for instance, one gets an equivalent effect to Unix redirection by rebinding *standard-input* or *standard-output* to file streams). There is no good way to do this if you don't have dynamic scoping. Programs that rely heavily on dynamic scoping are usually sloppily written and extremely difficult to analyze - things go on behind your back all the time. Default dynamic scoping in Lisp is the result of history - in 1958, programming language semantics was not well understood! In another 20 years, no one will understand why anyone would suggest that default dynamic scoping was a good thing. >to allow both dynamic and lexical makes the performance even worse. This is totally wrong. >lexical scoping was and should be a compiler OPTIMIZATION, not an inherent >part of the language semantics. Great - a program that works interpreted, because it relies on dynamic scoping and your misnamed variable that happened to have been bound a while ago, will not work because your officemate that you gave a copy of the compiled code to doesn't have that same variable bound in *his/her* Lisp! Changing dynamic to lexical scoping is a massive and dramatic change in program semantics - I prefer my compiler optimizations to affect speed and not meaning. >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... To put things in perspective, the Zetalisp language (that the Symbolics people sell like hotcakes for big bucks) is at least an order of magnitude larger and more complex than Common Lisp, which they consider to be a small subset for the exchange of programs. All reports have been that the Symbolics is super-fast for development and for execution... does anyone want to contradict me? >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 Neither would I - it's not *supposed* to be an instructional book. Does anyone tried to learn Ada from the ANSI standard? The Common Lisp standard is very nice for implementors. I appreciate the explanations and comparisons to other Lisps and I enjoy the jokes. There are some problems, which is why there is another version in the works. Almost all of the problems are extremely technical, and take a long time just to explain to someone not familiar with the language, let alone to solve... There are also some open problems with language design involved - like compiling to different machines within the same programming environment, and support of program-analyzing programs in a portable manner. >...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. A competent implementor should and will know about a bunch of implementations. *I* didn't have any trouble with the references to other Lisps... >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! Finally, a semi-valid point. There has been some effort to define various subsets, but no consensus has emerged. Any time someone defines a subset, everybody whose favorite feature has been left out will rant and rave and insist that it be included. By the time you're done, you've got the whole language again (spoken from personal experience!). As for the non-use of Lisp definitions, most such definitions are either simple and wrong, or complicated and right. The Spice Lisp sources are in the public domain, and people often look at those for ideas. See the comment about freedom of implementation above. >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 (!!). Reports about the death of SETQ and SET have been exaggerated for a long time... > 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? Chapters 3 and 5 contain information about scoping and binding rules. Guy Steele has mercifully not repeated the obvious throughout the book! To answer your question, (SETF x y) *always* expands into (SETQ x y); see the top of page 94. SETQ sets the lexical binding if there is one, otherwise the dynamic binding; see the definition of SETQ on page 91 (where there is a reference to the "usual rules"), and the definition of "usual rules" in the section on variables, p. 55. I think it would be impossible to write a language standard that caters to those who can't read. >"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... Well, it doesn't seem more consistent to *me*! Should we take a vote? Should we weight the votes in inverse proportion to the ignorance of the voter? >Care to explain this to a "beginner"? Suppose you want to write a macro that expands into something with a SETF in it. Now suppose that this macro has an list of variables that all need to be SETFed. If (SETF) is valid, then the list of things need only be appended - if an empty list is not valid, then the macro will have to test for this first and do something else if the list is empty. Also, in the obvious recursive definition of SETF, expanding (SETF) into NIL is a nice termination case. Note that this is all convenience; if you like to suffer while programming, use Pascal. > Not to mention that SETF is a >MACRO, by definition, which will always take longer to evaluate. Bogus! This is only true for *some* interpreters and *never* (so far as I've seen) for compilers. In fact, many expert Lisp hackers replace functions with equivalent macros when possible, to save function call overhead (I don't recommend this practice, most compilers have hooks to opencode user functions when requested). >Then try explaining why SET only affects dynamic bindings (a most glaring >error, in my opinion). So how in the world are you going to get this to work in a compiler that compiles lexical references into positions on stack frames? (let ((var (if (random-predicate) '*realvar1* '*realvar2*))) (set var 45)) Remember, SET evaluates *both* arguments, so it can't know the variable name until runtime. Here's another example: (set (read) 45) Since (set x y) == (setf (symbol-value x) y), it applies only to the dynamic binding (read the definition of SYMBOL-VALUE carefully). > Again, how many years of training, understanding >and textbooks are suddenly rendered obsolete? Those folks that managed to pass CS 101 shouldn't have any problem. > How many books say >(SETQ X Y) is a convenient form of (SET (QUOTE X) Y)? Probably all >but two... I use my Lisp 1.5 manual for historical research only (sorry JMC). >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). Perhaps you should try a non-broken Common Lisp then... >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! So what is Real Lisp anyway? Show the definition so we can flame at it! >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? MEMQ is a stupid name. >MEMBER isn't the only case... This was a tough problem for the designers. On the one hand, everybody complains about non-obvious names like CAR and CDR and MEMQ. On the other hand, the considerably better name MEMBER, which ought to be used to denote *all* sorts of membership tests, had been grabbed up for EQUAL tests. I would rather have one obvious function name than MEMBER, MEMQ, MEMQL, MEMBER-EQUALP, ad nauseam. And I *especially* don't want to write my own membership tests just because I needed to use some specialized test function!! >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. Guy Steele has profusely and publicly apologized for the fonts, even though it's actually the fault of Digital Press, who couldn't seem to manage a boldface fixed-width font (the manuals printed at CMU were much better). >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? I wish more people would think about the issues of language design before flaming about somebody else's design! I have no idea what Jeff Jacobs thinks Real Lisp is, but I do know what objections people have to Common Lisp. Most of those objections go away when they start to think about efficiency vs usability, or consistency vs sanity. For instance, many people object to the sequence functions, on the grounds that users could write them themselves. So what users want to try writing SORT? Probably only those with all kinds of time to waste getting a decent algorithm, debugging fencepost errors, etc. The smart users will suggest that it be a library function written in Lisp. Ah, but what should be the interface be? Two arguments, a sequence and a predicate? One argument, a sequence, and a global variable *sort-predicate*? How about two global variables and a 0-argument function (don't laugh, people really do these sorts of things sometimes). Will the sort be stable or not? Now it's unlikely that two different sites will define their library SORT function to be quite the same. So the poor person faced with porting a program must carry along all the libraries from wherever the program was written. The even poorer person will have to combine programs from several different places, each with a different sort routine, and try to prevent each definition of SORT from stepping on the others. At this point, standardizing on a sort function should seem like the right thing. Fortranners and Pascallers and Cers don't worry about this sort of thing, because they just write sort routines and membership tests over and over and over again, and wonder why they have to work 10 times as hard to get their programs as sophisticated as the same ones in Lisp. Speaking of Fortran, why do people think having complex numbers and different sizes of floats makes a language large and complex? Perhaps it's rationals and bignums that make the language too complex? Personally I'm much happier when (* (/ 1 2) 2) = 1 instead of 0, and when (+ 2405920349 2452458405) is not 45. There's something to be said for mathematical sanity, which is why symbolic algebra systems have rationals and bignums. Maybe character objects are bad, but somehow I can't excited about trying to remember that 121 actually means 'y' (at least in ASCII, which is not the only character set in the world). After all, isn't Abstraction a Good Thing? I think those who flame about language designs should be forced to design, implement, and distribute their own language, then listen while know-nothing second-guessers complain about things they don't understand to begin with... >Jeffrey M. Jacobs stan shebs