SBCL perspective #
hacking, December 2nd 2006
As you've undoubtedly heard by now, SBCL 1.0 is out with plenty of improvements, so I figured this might be a nice time for a personal SBCL & Common Lisp retrospective.
My first introduction to lisp in the form of Scheme was in the autumn of 1996 at the university, on the SICP course. While I learnt a great deal on that course, Scheme really didn't stick. It wasn't until late 2002 that I got my first taste of CL. I don't remember the first contact, but I do remember the first time I happened on CMUCL.
What? An optimizing native compiler for a language this dynamic and cool? What is this, some sort of a joke? And this thing seems to have been around since forever! Why have I not heard of this before?!
Then, over the Christmas holidays 2002 I rewrote my toy raytracer in CL (for CMUCL). While the performance did suffer, it didn't suffer too much for my purposes — and my code was typical newbie code. Not too great CL, and not too well optimized. No matter. I was in love.
For a while I tried both SBCL and CMUCL, and gave GCL and Clisp a try too. How and when I picked up SBCL for good, I don't really remember, but I think I was hooked by touching the source. My first patch (a trivial build fix) appears on sbcl-devel on 31st of May 2003, just a few weeks after my first question on sbcl-help (which seems to indicate I was definitely using both CMUCL and SBCL). Then, several patches and a year or so later I was blessed with commit access in May 2004, and the rest, as they say, is history. Just a couple of short years later, here I am, trying to make a living out of my mad SBCL skillz.
So, what makes SBCL so utterly cool that spending all that time on it wasn't a waste?
- Successor to CMUCL, probably. For a long time I would have hesitated in saying this, but not any more. Unless CMUCL gets re-invigorated with new developers it will (sadly) be ultimately superseded by SBCL for all practical purposes — so for the time being, SBCL is the only portable open source highly optimizing Common Lisp compiler of note with a future in my books. This is not slam on CMUCL or CMUCL devs. They have done great work and keep doing great work, and the cross-pollination between SBCL and CMUCL has benefited both. I just don't personally believe CMUCL has another decade in it left, whereas SBCL almost certainly has.
- Number crunching. Writing good numeric code in CL takes some skill, but once that is obtained SBCL can do very well indeed — and is getting better all the time. CMUCL is on par, and AFAIK ACL is quite competitive too, but doesn't allow inlining of user-defined functions. Scieneer is probably on par or better, considering its heritage.
- Hackability. SBCL is easy to build, and once you get your bearings quite hackable. Deep parts of the compiler remain deep parts of the compiler, but getting your bottleneck optimized or having the niggling library bug taken care of isn't usually all that hard. And being not just open source, but mostly in public domain you really don't have any licence issues what so ever.
- Package locks. If you ask me, SBCL is the only Common Lisp that gets package locking mostly right. But I would say that, would I not?
- Timeboxed releases. SBCL releases once a month. This means that even without following the bleeding edge you don't have to wait long for your bugfixes to appear in an official release. (The downside is that incompatible changes can sometimes happen in rapid succession too, which is where my company Steel Bank Studio Ltd can help you by maintaining a stable release that gets backported patches but doesn't break source-compatibility. Get in touch — the rates are quite reasonable.)
- SMP threads. As far as I know only SBCL, OpenMCL, and Scieneer offer SMP lisp threads. While SBCL's threading does still have some issues, the work is progressing, and quite some people seem to be happily using them too. (Note that I would not with good conscience at this point recommend using SBCL threading with CLOS heavy code in a critical application, but I'm hoping to drop this reservation in a month or few.)
- Smart people. I really like most of the people associated with SBCL because they make me feel slow and stupid. That may appear a strange sentiment, but it really is a quality you should appreciate in your co-developers. As they say, there are two kinds of people: those who prefer the company of people more intelligent then them, and those who prefer the company of people less intelligent then them...
Is that all? Of course not! There is modular arithmetic using standard CL operators. There is a rather dynamic FFI supporting callbacks. There is a sampling profiler that also does allocation profiling. There...
Hm. That was one undirected ramble. Sorry about that.