>The main issue people have with the book is that it uses CLISP-specific code in a few places.
This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP.
The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offering more features. Also, code runs very fast under SBCL; although i suspect that CLISP compiles code faster.
(If any is interested, here is a quick overview on some of the Lisp implementations available and their salient features.
(Most implementations are free)
ECL - Embeddable Common Lisp
allows you to compile Lisp into any
other system by compiling to C
SBCL - Steel Bank Common Lisp
Produces very fast code,
allows static type checking and other niceties
a fork from the CMU CL impl.
CLISP
Small, easy to install and use,
includes readline REPL and X11 features
ABCL - Armed Bear Common Lisp
Allows you to run Lisp under the Java JVM
and call Java code, or call Lisp code from Java.
CLASP
Compiles Lisp to the LLVM, provides C++ interop
ACL - Allegro Common Lisp
Commercial Lisp, fast, feature rich
includes a Prolog implementation, CLIM GUI
and other nice stuff.
LispWorks
Commercial Lisp, fast, feature rich,
includes an IDE, Java Interface,
and CLIM 2.0 implementation, more features.
ParenScript
This is a small subset of CL that gets translated
(in the server) to javascript
JSCL
A Lisp implementation that runs under Javascript,
providing a REPL and Lisp interpretation on the
browser, for a subset of the CL language.
)
CCL - Clozure CL
Produces fast native code; compiles faster
than SBCL. Also has some MacOS-specific goodies.
People sometimes use both CCL and SBCL at the same time, to have faster compiling during development via CCL and then better runtime performance of the released version via SBCL.
I used to use CCL for hobby gamedev back when SBCL had some troubles on Windows (they're gone now); now I only use it on Raspberry Pi (AFAIK SBCL couldn't utilize multiple cores on ARMs last time I checked (which was a years ago)).
It is also because CLISP is unmaintaned. But the only implementation dependant code I remember is the socket code.
But CLISP wasn't unmaintaned when the book was written más its default REPL is much better than other implementations. It was a good choice at the time.
AFAIK, it is not really unmaintained, the developers just haven't done a release in years.
When I fire up CLisp on openSUSE Tubmbleweed (their rolling release distro), it says
Welcome to GNU CLISP 2.49.60+ (2017-06-25) <http://clisp.org/>
That would make me think that development might have slowed down, but not stopped.
Yet, if you visit that URL, you are greeted with :
Current version: 2.49 (2010-07-07)
Seems like the patch level on openSUSE is provided by the package maintainer, not CLISP. It looks like Debian Wheezy is at "2.49-8.1", Ubuntu Xenial is at "2.49-9ubuntu1", FreeBSD Ports is at "2.49_6", but also marked deprecated/expired as of 2014.
I'd venture that the maintainer is applying patches to the upstream source to keep it running on the OSes when they update ABIs, etc.
>I wish one implementation triumphed over the others
That would be terrible. Part of the nice things of CL is that you can choose the implementation according to what you need. For example ECL if you want to embed your lisp code with C code. ABCL if you really need to call lots of Java libs (or have Java code call your Lisp code easily), and so on. We're talking about mature, proven, tested implementations.
If one implementation triumphed over others, over time we'd be in a position similar to, say, Python or Clojure, where there is only one or two implementations, besides some experimental implementations, and nothing else.
Something that needs to be mentioned is that CL is truly standardized; if you have a code written in Common Lisp, chances are it will compile straight away on most of the implementations (ECL, ABCL, SBCL, etc), with no change needed. So having many implementations does not mean there is any kind of fragmentation in the language.
>and CL progressed beyond its ANSI standard.
CL is one of the most extensible languages out there, so it has already progressed way beyond the ANSI standard. The standard doesn't need modification to support new things. There are already many libraries giving you things that are not in the standard (like sockets or threads) but in a portable and standarized way.
But the whole idea, to your own point, is that there are lisps everywhere, compiling to everything and each having specialized additional features for the local needs, yet the ansi core remains intact, so everyone can use every one of those lisps (if they really are lisps...I’m looking at you, clojure!) [ED: I’m good with RSR5 too ... Jerry Sussman himself calls scheme a Lisp!]
He can always reuse code from other implementations.
Though I agree that it is too much work for a single person to create a quality implementation of Common Lisp.
Problem seems to be that there is not enough interest in another implementation based on an un-explorered infrastructure (LLVM).
This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP.
The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offering more features. Also, code runs very fast under SBCL; although i suspect that CLISP compiles code faster.
(If any is interested, here is a quick overview on some of the Lisp implementations available and their salient features. (Most implementations are free)