Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!mit-eddie!husc6!necntc!adelie!mirror!cca!lmi-angel!rpk From: rpk@lmi-angel.UUCP Newsgroups: comp.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <141@lmi-angel.UUCP> Date: Fri, 13-Feb-87 17:56:14 EST Article-I.D.: lmi-ange.141 Posted: Fri Feb 13 17:56:14 1987 Date-Received: Sun, 15-Feb-87 15:48:56 EST Reply-To: rpk@lmi-angel.UUCP (Bob Krajewski) Distribution: comp.lang.lisp Organization: LISP Machine, Inc (Cambridge Engineering HQ) Lines: 116 Summary: Personal prejudice .vs. language design In article <> jjacobs@well.UUCP (Jeffrey Jacobs) writes: > >Some comments on "Against the Tide of Common LISP". > >1) To gauge the ongoing change in reaction over the past two years. >The first time parts of it appeared in 1985, the reaction was >uniformly pro-CL. > >When it appeared last year, the results were 3:1 *against* CL, mostly >via Mail. What exactly are you trying to imply here ? What were the circumstances of rejection ? >4. CL did not fix the problems associated with dynamic vs lexical >scoping and compilation, it only compounded them. My comment >that > >>"lexical scoping was and should be a compiler OPTIMIZATION" > >is a *historical* viewpoint... The interpreter/compiler dichotomy >is effectively a *historical accident* rather than design or intent of the >early builders of LISP. Well, it's a fairly large blot on language semantics. Common Lisp decided to get the semantics right, while not removing historical phenemona like the names of certain list manipulation functions (NCONC or RPLACA). >BTW, it is trivial for a compiler to default to dynamic scoping... Yeah, the Lisp Machine compiler used to allow that. It's pretty disgusting. It would also be trivial put a lot of other switches in the compiler that would permit it to be more ad hoc because it was more convenient to implement it that way. >I have so much heartburn with SETF as a "primitive" that I'll save it >for another day. Well, I'd like to hear them. It would be interesting to see what your objections are. >7. >MEMBER used EQ instead of EQUAL. > >Mea culpa, it uses EQL! Nitpicking aside, this is hardly arbritrary -- remember that since Common Lisp is a new dialect, there was only a secondary consideration in being compatible with other Lisp dialects. This decision was made, so there's no use complaining that MEMBER in Common Lisp is a different function than MEMBER in Maclisp. In a previous posting I indicated one solution for porting *existing* code. There is a need for various older Lisp -> Common Lisp compatibility packages, and to a large extent they can be very portable. >1. Interpreter Performance > >I believe that development under an interpreter provides >a substantially better development environment, and that >compiling should be a final step in development. It depends on what implementation you're using. Because the Lisp Machine effort was driven by system programmers and a specialized architecture, debugging compiled code is *easier* in most cases than debugging interpreted code. In non-specialized implementations, this is less likely to be true if not many conventions of a ``virtual Lisp machine'' are honored in compiled code. >It is also one of LISP's major features that anonymous functions >get generated as non-compiled functions and must be interpreted. This is another a priori opinion. How many mature implementations of Lisp actually behave like this in the first place ? What are the applications of a such an accidental behavior ? >3. "Against the Tide of Common LISP" >The title expresses my 'agenda'. Common LISP is not a practical, >real world language. OK, back to the crusade... >It will result and too expensive. To be accepted, LISP must be able to run >on general purpose, multi-user computers. It takes a consultant to come up with conclusions like this, and requirements like this... >There must be a greater understanding of the problems, and benefits >of Common LISP, particularly by the 'naive' would be user. You're talking about a group with little clout. If the analogous attitude were true in the personal computer marketplace, then everybody would have Macs; instead ``power users''are perfectly happy to tweak PCs. Everyone starts out naive, but people who want programs written will not tolerate naivete in the would-be implementors. Would be users are not catered to by a language definition, but by good textbooks, education, and lots of hands-on experience. >Selling it as the 'ultimate' LISP standard is dangerous and >self-defeating! Who said that ? Common Lisp is not a step forward in terms of Lisp ``features.'' By reining in the spec and getting diverse implementors to agree on something, I can write a program on a Sun, and have it work on (say) a Lisp Machine (Zetalisp), a Silicon Graphics box (Franz Common Lisp), a DEC-20 (Hedrick's Common Lisp), a VAX (NIL or DEC Standard Lisp), and so on. Before, one had to make a decision on whether to use a safe Maclisp subset or a safe Interlisp subset, if one indeed expected portability to be worth one's while at all. And then you got show off your expertise in #+/-, STATUS and SSTATUS, and the knowledge of n dialect's opinions on whether NTH was 0 or 1-based. At least now there is a Lisp which is no more repugnant than C (actually, at lot less, in my freely admitted biased opinion) as a portable programming language. -- Robert P. Krajewski Internet/MIT: RPK@MC.LCS.MIT.EDU UUCP: ...{cca,harvard,mit-eddie}!lmi-angel!rpk