Hacker News Reader

Comment by smanek | Hacker News Reader

I personally use SBCL, but I've heard a lot of people use Clozure Common Lisp (http://www.clozure.com/clozurecl.html) because it has better Slime integration (better stack frame inspector, etc).

The very best tools are probably Allegro CL (w/ its non-emacs IDE) and Lisp Works (and its own IDE too). I've heard nothing but good things about both (and have used Allegro CL enough to know it - and its associated libraries - are very impressive).

As far as I can gather no one really uses them since they are just too expensive though. They must be making money somewhere, I just don't know where ...

View on HN

I've heard a lot of people use Clozure Common Lisp (http://www.clozure.com/clozurecl.html) because it has better Slime integration (better stack frame inspector, etc).

Really? I would have said CCL has worse Slime integration in general (Slime being an epiphenomenon of the SBCL-on-Linux world) and far worse when it comes to debugging. Am I missing something?

We're using CCL with Slime on OS X. The Clozure people are working on a new IDE, but I don't know how good its debugging facilities are yet. It would take a lot to get me off Emacs, but slick debugging might do it.

Alternatively, I often think that maybe we should just take the time to make sldb do what we want. But it's hard to take precious resources away from one's main project.

If anyone feels the same way and is interested in hacking on this, email me - maybe we can work something out.

IIRC, ITA Software (one of the biggest Lisp houses in the world ...) uses SBCL for their main QPX project. A few years ago when they were starting the new Polaris project, they decided to go with CCL instead of continuing with SBCL.

My understanding is that the two major motivating factors for this decision were that CCL compiles faster and has better debugging support.

This is all based on my memory of conversations that took place about a year ago, so it's entirely possible I'm mis-remembering or what used to be true no longer holds. I have no first hand experience with CCL so if you do, I'll take your word for it ...

Remember also that during the time that ITA would have made that decision, SBCL and SLIME were both evolving rapidly.

I currently work on QPX, the air travel search engine. We continue to use SBCL, primarily because it produces faster code for our workload. We and our customers are very sensitive to the performance of the application.

Dan Weinreb, another ITA developer, did a talk at Google a few months ago on ITA's new reservation system (the Polaris project you mention). They do use CCL, but the code also compiles and runs with SBCL. The primary reason he cites in that talk for preferring CCL over SBCL (about 22 minutes in) is that CCL compiles code more quickly than SBCL.

I haven't used CCL much, but I understand SBCL and CCL have different debugging strengths. An SBCL developer tells me that a significant chunk of the compilation time for our application is in constraint propagation for types. That's part of the "generates more efficient code", but it also means that it's smart about telling you when you're doing something that's not going to work. For whatever reason, type propagation or otherwise, CCL won't do as much to help you at compile time. I am told that CCL gives better stack traces, so SLIME can help you more.

Yeah, that vibes with I've seen in SBCL (and been told about CCL). Thanks for the inside scoop.

Reply on news.ycombinator.com