In A Critique of Common Lisp written by Rodney A. Brooks and Richard P. Gabriel from Stanford in 1984, some design decisions retained by the normalizing committee of Common Lisp are discussed. While most of the discussion remains valid, there are two statements that refer to the technology available at the time and may be false today.
These two statements are:
Too many costs of the language were dismissed with the admonition that ‘any good
compiler’ can take care of them. No one has yet written—nor is likely to without
tremendous effort—a compiler that does a fraction of the tricks expected of it.
As I am a Common Lisp novice, or even an apprentice, I am not able to be more specific than the authors are. They seem to state that a great generality and flexibility has been built into several aspects of the language, which makes writing a good compiler quite difficult.
In COMMON LISP a little too much control was
placed on floating-point arithmetic. And certainly, although the correct behavior of a
floating-point-intensive program can be attained, the performance may vary wildly.
As far I understand, it seems that writing efficient numerical code in Common Lisp is possible but more challenging than it has to be.
This was thirty years ago. How should I regard these statement today if I am willing to write Common Lisp programs for one of the common free software implementations (CLISP, SBCL et al.)?
Best Answer
The paper is interesting in many ways.
The most interesting part is this: the authors falsified the paper from 1984 just two years later in 1986 themselves. Brooks and Gabriel developed a highly optimizing Lisp compiler and sold it commercially very successful for several years: Lucid Common Lisp (PDF).
Maintenance for this Lisp compiler is still available from LispWorks: it is now called Liquid Common Lisp.
The compiler optimizations of Liquid CL are documented in Chapter 3 of the Advanced User's Guide: Optimizing Lisp Programs.
Several commercial applications have been written and deployed in Lucid CL. For example in my home town the first public transport information system for the HVV (Hamburger Verkehrsverbund) was deployed using Lucid CL on a SUN SPARCstation. It was available for the public in train stations using a large touch screen and in the call center.
Lucid CL was successful because its production mode compiler created fast Common Lisp applications, mainly for Unix / RISC platforms.
Brooks and Gabriel are writing about Lucid Common Lisp in 1986:
Thus they had just implemented what the A Critique of Common Lisp claimed to be difficult or impossible.
Nowadays the more advanced implementations are doing a lot of optimizations, but the hardware is also 1000+ times faster than what we had in 1984. A VAX 11/780 then had one MIPS (million instructions per second) and a Lisp Machine was also in that range. A Motorola 68000 had a clock rate of 8 MHz.
The criticism about floating point performance and generally varying performance is still valid, but this reflects implementors choice. Some implementations are not developed as high-performance compilers. Their main focus could be portability, compactness or something else and thus they have different implementation goals.
As a user/developer one is not forced to write portable code and use all of the ten+ currently supported Common Lisp systems. Use the implementation which is best suited to the application problem.