Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!im4u!milano!mcc-pp!patrick From: patrick@mcc-pp.UUCP Newsgroups: comp.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <2626@mcc-pp.UUCP> Date: Thu, 12-Feb-87 10:44:22 EST Article-I.D.: mcc-pp.2626 Posted: Thu Feb 12 10:44:22 1987 Date-Received: Fri, 13-Feb-87 06:34:47 EST References: <2573@well.UUCP> Distribution: comp.lang.lisp, mod.ai, comp.ai Organization: MCC, Austin, TX Lines: 100 Summary: An alternative view... As a new arrival to the Lisp world (2 years experience with Lisp, vs 15 with C, Bliss, and Fortran), I think I have a different view of Common Lisp vs other Lisps than either the definers of the Common Lisp standard or jjacobs. ... On compilers vs interpreters As a systems and performance measurement type, I have always been concerned with how fast my programs run. One of the critical measures of success of OS code is how fast it is perceived to be. My default programmer's model says interpreters are slow. Also, old rumors about programs behaving differently in compiled and interpreted mode made me distrust the interpreter as a naive user. Since I have an incremental compiler (Lisp machine), I compile everything before I run it, except top-level commands. I have not noticed significant impediments to development using this procedure. Breakpoints and function tracing are still available as well as the old, old reliable of print statements. Indeed, when at a breakpoint, I can rewrite and recompile any function that I am not currently within. Thus, from my viewpoint, all discussion of how fast something is in an interpreter is irrelavent to my purposes. Dynamically created closures can also be handled by an incremental compiler. I claim that this approach to Lisp development is followed without lossage by many of the new arrivals to the Lisp world. ...on Common Lisp environments I recognize that Lisp machines are too expensive for most developers, but workstations such as Sun now have Common Lisp compilers (from Kyoto, Franz, and Lucid at a minimum), with runtime environment development continuing. I claim that reasonable Common Lisp development environments are available on $15,000 workstations and multiuser systems such as Vaxes and Sequents today, and will be available soon on $5000 PCs (based on high performance, large address space chips such as M68020 or Intel 386) ...on portability Implementors of major commercial programs want as wide a potential market for their product as possible. Thus, they chose to implement in the best available PORTABLE environment, rather than the best environment. Common Lisp appears the best choice. Researchers without the requirement for portability may chose other environments such as Scheme or InterLisp. ...on commonality I was shocked to discover that MacLisp and InterLisp are significantly more different than C and Pascal. I am surprised that they are commonly lumped together as the same language. Scheme is yet farther away both in syntax and philosophy. All are in the same family just as C and Pascal are both related to Algol60, but beyond that... ...on Common Lisp the Language I learned Common Lisp from Steele's book and found it heavy going. A excellent first effort for defining a standard, but definitely not a teaching or implementators aid. The intro books are becoming available (with some lingering historical inconsistencies). Someone should write a book describing the "definitive" core of the language, followed by reasonable macros and library functions for the rest of the language. It would be a great aid to experimental implementors. Commercial implementations would continue to set themselves apart by the quality of their optimiziers, debugging environments, etc. <> On the other hand, with only a brief exposure to Franz Lisp and MultiLisp before plunging into Common Lisp (with ZetaLisp extensions), I did not have the disadvantage of historical assumptions about the definition of Lisp. ...on dynamic vs lexical scoping Common Lisp did not go far enough in lexical scoping. Specifically, it did not provide a way to define a lexical variable at the outermost level. As it is, I cannot define global variables without some risk of changing the performance of some function that happened to use the same variable name, even if the variable is used in a lexical way. The current recommended convention of defining specials with *foo* leaves much to be desired. Other than a globals, the only other uses I have seen for for dynamically scoped variables is to pass additional values to and from functions without using the argument list (generally considered poor practice by software engineering types, but occasionally preferred for performance reasons). I seem to have rambled on, but I agree with Jeffrey Jacobs in saying: > There must be a greater understanding of the problems, and benefits > of Common LISP, particularly by the 'naive' would be user. > > Selling it as the 'ultimate' LISP standard is dangerous and > self-defeating! Instead, I consider it the current Lisp standard, subject to "slow and careful" revision and improvement. By comparison, Fortran 77 is not Modula2, but it is far better than Fortran II. I hope and expect "Common Lisp 2000" will represent significant improvements over Common Lisp, perhaps with some remaining historical uglynesses removed or better hidden (including dynamic scoping). -- Patrick McGehearty, representing at least one view of the growing community of Lisp users.