The Best Open Source CL Implementation
Monday, April 3, 2006
A couple of years ago, I outlined some criteria for what I thought was needed in an open source Lisp implementation:
- Free: The implementation must be "free" in the general sense of the word (not require a payment to anyone in order to download it).
- Source Code: Source code for the implementation must be freely available.
- Strong Developer Team: The product needs to be well-supported by a group of talented developers.
- Active User Base: There should be a set of users who actively contribute to the development of code for the implementation. This is represented by both the range of 3rd party libraries that are provided for the implementation and news groups (and other information sources) dedicated to the implementation.
- Strong Library Support: Users often decry the fact that Lisp implementation "x" does not have available libraries to do some common task (e.g. -- XML parsing, HTML generation, regexp's, etc.).
- Expanding/Captive User Base: Ideally, the implementation will be used in a "killer" application or for some application area which generates new users. This is as important for injecting "new blood" into the development process as it is for ensuring that continual feedback will be provided to the core developers.
- Capable of Generating Stand-alone EXEs: People want the ability to easily distribute their application without requiring the download/installation of the full Lisp implementation.
- Supports All Major Software/Hardware Platforms: There need to be versions for Windows, .Net, Mac OSX, Unix, Linux as well as the major hardware platforms.
- Easy to Port/Embed: Some developers will want to port the implementation to an unsupported platform - this should be a realistic task. Others will want to embed it - this should also be achievable.
- Good Development Tools: There should be either good development tools available for the implementation or utilities that facilitate/enhance development with standard tools. Ideally, support for both beginners and experienced Lisp developers should be provided.
- Good Documentation: Full documentation of the implementation, extensions, libraries and development environment should be available (either as part of the implementation or from 3rd parties).
Here's how SBCL meets the set of criteria I specified in my earlier post:
- Free: Most of SBCL is public domain; however, there are parts of SBCL that are covered by other open source licenses.
- Source Code: Source code for both the implementation and the libraries is available.
- Strong Developer Team: Although there is no one working "full-time" on SBCL, there are a number of developers contributing on a regular, on-going basis and at least one person who plans to start working full-time on commercial SBCL support/development.
- Active User Base: SBCL seems to have one of the stronger user bases of the open source CL implementations.
- Strong Library Support: Most libraries that target more than one CL implementation include support for SBCL.
- Expanding/Captive User Base: It's hard to measure user counts of an open source project; however, if you use "mentioned in c.l.l. or #irc" as a metric, SBCL usage seems to be growing relative to other CL implementations.
- Capable of Generating Stand-alone EXEs: Since release 0.9.10, SBCL has been able to generate stand-alone executables (but not on all platforms).
- Supports All Major Software/Hardware Platforms: SBCL is
now available for most popular platforms (see diagram below). It used to be that if you wanted an open source CL implementation that
ran on Linux, Windows, and Mac OS X, you were limited to using
CLISP. With the recent enhancements, SBCL now seems to be the logical
choice for anyone who needs an open source, cross-platform CL
implementation. In fact, the the
diagram below shows that SBCL is probably the CL implementation with
the most number of platform/processor implementations:
- Easy to Port/Embed: SBCL has been ported to many platforms and the development team has always shown support for helping with other ports.
- Good Development Tools: For most SBCL developers, SLIME/Emacs is the tool of choice. Although this combination is available for other CL implementations as well, SBCL support of SLIME functionality is as good (or better) than most other implementations.
- Good Documentation: Full documentation is available (online or downloadable) in HTML, TeXInfo, and PDF formats.
- New platform support: Experimental support for SBCL x86/Darwin, including MacOS X 10.4.5 on Intel. Support for the Windows operating system has been added.
- Stand-alone Executables: The new SAVE-LISP-AND-DIE keyword argument :EXECUTABLE can be used for bundling the runtime and the core file into one executable binary. This feature is not currently supported on all SBCL platforms.
- Garbage Collection: Major improvements to GC efficiency on GENCGC platforms. A generational or ephemeral garbage collector is now the default on the PowerPC platform (both Linux and Darwin). The old Cheney (stop and copy) collector is a build-time option.
- Threads: Although not yet included in any SBCL release, there has been some progress in adding thread support to some of the other SBCL ports (at present, the only SBCL implementations that support threads are x86/x86-64 with Linux kernel 2.6 or systems with NPTL backports). Daniel Barlow did the initial SBCL thread implementation on Linux but Cyrus Harmon and Nathan Froyd appear to be doing most of the work on adding threading support for other SBCL ports. For me personally, the lack of threads for SBCL on Mac OS X has always been a bit of a handicap and one of the reasons why I have tended to use OpenMCL more frequently on Mac OS X.
Update-2006-04-06: Christophe Rhodes (one of the SBCL maintainers) sent me a (fair) critique of my post titled "Oh, the irony" (reproduced with permission):
"Just as I complained bitterly about your PLT Scheme-as-best-Lisp a couple of years ago, I think it's only fair that I complain about your SBCL-as-best-Lisp now. Some people are never happy.
The issues I have with your post basically boil down to putting too rosy a face on things, or obscuring with sleight-of-hand (though not deliberately!), and since I complain when this is done to the detriment of SBCL's perception, I think it's only fair to do likewise when the perception might go the other way. But before I start, thanks for the positive review :-)Anyway, that's enough nitpicking. Thanks again!"
- SBCL is probably the CL implementation with the most number of platform/processor implementations
I strongly doubt this. Even ignoring Allegro (if you add the word "free" in there) clisp and gcl both run on 11 architectures, as opposed to SBCL's paltry 6; ABCL runs anywhere a JVM does; and ECL is portable to anything where GMP and the Boehm-Weiser GC run.- Easy to Port/Embed: SBCL has been ported to many platforms and the development team has always shown support for helping with other ports.
Somewhat similarly, I wouldn't describe SBCL as easy to port. Not too difficult, perhaps, but not easy: it's in the man-weeks range. Compare to ECL's ease of portability and while I think your statement is accurate, it's perhaps a little unfair, particularly when you consider that it's practically impossible to embed SBCL.- Good Documentation: Full documentation is available (online or downloadable) in HTML, TeXInfo, and PDF formats.
Whatever else you call the online documentation, please don't call it "full"... it is very much in progress, and there's plenty of stuff that isn't documented properly.- Capable of Generating Stand-alone EXEs: Since release 0.9.10, SBCL has been able to generate stand-alone executables (but not on all platforms).
Whether people are happy with 30MB stand-alone executables is another matter...
