SBCL and CLISP… take two.

I got a recent comment on my cite:

(Quote of me: “If Common Lisp is as inconsistent as this, maybe it deserves to be as low on the programmatic food-chain as it is.” After all, I’ve never had a problem as sever when using the closed or open source JDK’s.)

Sure, because they were all the same language. We talk about “Lisp” as if it were a single language, but really, it’s a family of languages. SBCL and CLISP are interpreters for two different languages altogether. They’re similar and largely compatible, but you can’t compare them to JDK, because SBCL and CLISP serve different functions.

If this is your main complaint with Lisp, it seems like a fairly petty and ill-deserved one.

And I thought I might put the full response up:

You know, I actually have a far, far higher opinion of Lisp over the past year. I’ve read the histories by McCarthy and Steele, I’ve learned the origins of Lisp-1 vs. Lisp-2, and I am grateful for it (I am totally in the Lisp-1 camp). and I honestly wish I had the time (and could find the employer) to work with Clojure full time.

I’ve actually meant to go back and revise this post, or at least link to a better one comparing SBCL and CLISP but I never had the opportunity. I find it very amusing, and somewhat unfortunate, that this has such a high ranking on certain search engines on that topic as I was far less educated on the topic than others (and I know at least a little better now), but I don’t have time and I haven’t read anyone who has written the article I’d like to link to.

That said. SBCL and CLISP both claim to support the ANSI Common Lisp specification (something which, I might add, even some of the authors have bemoaned as an overly-complicated mess). Remember what they both stand for: SBCL is Steel Bank Common Lisp; CLISP is Common Lisp. So really, they can be held to largely the same standard, and I do retain my meta-opinion. SBCL has performance and CLISP has usability.

Personally, if I were to choose one, I generally will choose usability over speed, because most of the time, any extra time I would gain in processing power will be lost ten-times over in man hours. Given the choice between me spending time at a computer trying to get something to compile, and time away from the computer waiting for it to compile itself, I prefer to go get some coffee. This goes along well with the quote:

People are expensive, equipment is cheap.

Programming languages and environments must take the same rules about user experience for them to do well and, as a general rule, usability can directly parallel consistency. If something is simple and easy to use, it will be used consistently and largely in the same way. It will be easier to maintain it, and things related to it.

There is a reason that there are so many Python zealots out there, there is a reason that in Python 3 you can simply import antigravity. No, it is not as fast as C or C++, and the war (and yes, it’s a war) between Python 2 and Python 3 continues to rage on, but it just works. It is simple, easy, and generally obvious.

And I would say the same about CLISP, at least in comparison to SBCL (Clojure is, in my opinion, superior to both, but that is another matter). And because of that, I maintain that opinion and, unless you can provide the article I mentioned earlier, I will continue to maintain that.