Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!gatech!lll-lcc!well!jjacobs From: jjacobs@well.UUCP Newsgroups: comp.lang.lisp Subject: Against the Tide of Common LISP Message-ID: <2602@well.UUCP> Date: Wed, 18-Feb-87 02:18:59 EST Article-I.D.: well.2602 Posted: Wed Feb 18 02:18:59 1987 Date-Received: Thu, 19-Feb-87 06:46:50 EST References: <2601@well.UUCP> Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs) Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 181 In <2626@mcc-pp.UUCP>, Patrick McGehearty writes: >... 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. We not only share a common background, but a common *concern*; that of performance! In fact, this is one of my biggest gripes about Common LISP; in exchange for very little, if any, improvement in functionality, it requires an enormous increase in CPU and memory. It is hard to believe, but combining all those options for LAMBDA lists, allowing the 'initform' of DEFVAR to not be executed until the variable value is needed, implicit lexical closures, etc result in a dramatic increase in CPU and memory requirement, both directly and indirectly. The worst part is that you *cannot* get around them! You can elect to use SETQ instead of SETF, but you can't elect to use MEMQ instead of MEMBER! >Also, old rumors about programs behaving differently in compiled >and interpreted mode made me distrust the interpreter as a naive user. Well, Common LISP is supposed to be the same. Most experienced LISP programmers will tell you that even with the differences between compilers and interpreter, it was seldom a problem. >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.. >I claim that this approach to Lisp development is followed without lossage >by many of the new arrivals to the Lisp world. You can't know what your are missing if you've never had it! Interpreted LISP can provide an debugging and development environment that is far beyond that of break, trace and print! There is a tremendous amount of seminal work, primarily in and from InterLISP, that is only possible in an interpreter. Such things as automatic error correction, being able to change a function that you are currently 'in', being able to alter and modify the flow and results of a lengthy computation, etc. I've worked in situations where Integration and Test literally can take hours or days; the ability to change something that is in progress without having to restart from scratch would be an enormous asset in such situations. I recommend looking at some of the capabilities of InterLISP (or even UCI LISP) to understand what is potentially being lost. >...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) To quote a system manager, "Common LISP is a great tool for turning a VAX 780 into a single user machine!" To quote Charles Hedrick, "Personally I would have wished for CL to be smaller. As the manager of a number of timesharing systems, I cringe at a Lisp where each user takes 8 MB of swap space" The problems is that you have been hoodwinked into believing that you can't have similar capabilities and functionality without a LISP machine or dedicated workstation. (Do you think the LISP machine vendors would have been happy with a small core of primitives that would run on anything, and with successivly complex layers for those who want them?) The French produce a LISP called Le_LISP; it is "standard" across VAXes, MS/PC-DOS, MacIntosh and various 68000 workstation. There is also a VLSI implementation in progress. They begin by defining a very simple "virtual machine", with a great deal of thought given to how people actually write LISP code, (as opposed to the CL committee, whose basic approach was how people *might* want to write code :-). According to Dr. Lee Rice of Marquette (DEC Professional, March 1986), Le_LISP on a VAX 780 supported an additional 37 student for an AI class with no noticeable degradation even during peak periods! The Rice article gave a simple FIBONACCI benchmark; interpreted, LE_LISP on a VAX 780 took 4.25 seconds, compared to 8.9 for VAX InterLISP, 16.1 FRANZ and 29 seconds on a Symbolics. "Optimized Compiled" gave 0.12 for LE_LISP and 0.15 for Symbolics. (BTW, anybody having Gabriel benchmarks for LE_LISP on other than Mac or PC, please let me know). The Macintosh version will run on a 512K MAC, and will execute the BROWSE benchmark! I know of no other serious commercial implementation that will run BROWSE in 512K. It runs TAK on a 512K MAC in 62 seconds, *interpreted* (and remember that the MAC has a ridiculous amount of overhead). So take your daily dose of salt! >...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. Most implementors of commercial Expert Systems have *abandoned* Common LISP, primarily due to the abysmal performance. Portability is certainly desireable in a language, but the high cost of CL far outweighs it's 'portability'. Common syntax and semantics are wonderful, but the ability to run in a cost effective manner is also important! >...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... You will also notice that InterLISP is *one* language, whereas MacLISP is the root from which almost all of the other dialects sprang. (I also don't consider SCHEME to be a LISP dialect; I consider it a separate language, with similar syntax). You will note that I have not defended any particular dialect of LISP. My main complaint is that Common LISP is not only not an improvement on other dialects, but is a major step backward in language design. Common LISP is enormously wasteful of CPU and memory, and ignores nearly all of the lessons learned throughout the years in the field of software engineering. >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. There is no "definitive core" at this time, (nor is there a conceptual core). If you examine the history of LISP, it started with a very small, well defined set of primitive and grew explosively. But as large as it grew, it was still defined in terms of 'smaller' operations. See the NEW UCI LISP Manual and the InterLISP manual, or, if you can get your hands on one, an old MACLISP manual. It is hard to believe that a language with LISP's historical roots would result in something as broadly defined as Common LISP. Hopefully, the ANSI Committee will improve on the situation, but I doubt that the fundamental design flaws can be eliminated. >-- Patrick McGehearty, > representing at least one view of the growing community of Lisp users. Jeffrey M. Jacobs CONSART Systems Inc. Technical and Managerial Consultants P.O. Box 3016, Manhattan Beach, CA 90266 (213)376-3802 CIS:75076,2603 BIX:jeffjacobs USENET: jjacobs@well.UUCP P.S. You do know that the real motivation behind the development of LISP machines was to have something to run EMAC on? :-)