Poll: Which Lisp implementations do you use?

[findinglisp]

I was curious which Common Lisp implementations are the most used. Hopefully, this will provide some data. I'll allow you to choose 2, as you might use different implementations on different platforms. In the comments, you might explain why you chose the way you did. What attracts you to a given implementation? If you choose "other," tell us in your comment what you implementation you use. I had to drop Schieneer and Armed Bear (ABCL) from the list, for instance, because the polling module only lets you have up to 10 choices. Hopefully, those have lower usage than the others.

[qbg]

SBCL is my implementation of choice.

I had a hard time choosing #2. I almost always use SBCL on Linux, and I use it from time-to-time on Windows too, so I don't end up using CLISP as much as I have done in the past. My #2 is the LispWorks (Personal Edition), because it provides a great environment for what Lisping I do on Windows.

My (only?) gripe with SBCL is the size of the images. Loading a 65 meg image (why did I put StumpWM in it?) at 3 megabytes/second from a NFS server takes time.

[Paul Donnelly]

SBCL is the one I use for programming, but I run StumpWM in CLISP, so it's technically the one I use the most. I like SBCL, but I'm working with 512MB of memory here, and I'd rather ease the pressure. Not being able to run a swank server alongside my window manager is driving me nuts though.

[TheGZeus]

Paul: I think I've seen you on Stump's IRC channel, and I'm sure there are ways to get the heap size down.

[vityok]

I use SBCL on Linux/FreeBSD and CLISP on Windows.

[schoppenhauer]

I use both, CLISP and SBCL, mostly SBCL, even under Windows I often use the experimental Version, because it mostly works, but I like CLISP because it is small and created with the purpose of Portability. Sometimes I try to run my Code under Allegro CL (the free edition for Linux), and it seems to be very fast, but since I am not a commercial programmer, I dont think that its the right choice for me.

A very interesting Approach seems to be ECL, as it uses a C-Compiler as Backend, and limits the Platform-Specific stuff. It has a few drawbacks, i.e. I dont actually know if it has weak pointers yet, and I think in some cases it is slow.

[phil]

I use SBCL on Linux, CCL on MacOS X and CLISP on Windows. I've had surprisingly few portability issues with this combination. That said, I'm interested in how SBCL is working out for people on Windows...is it at a point that you would recommend it on this platform?

[makia]

both CCL and SBCL on linux/osx
CCL is better if you are woring about SBCL memory usage, CCL is also fast implementation (meaby not like SBCL) , also threading in OSX is more mature in CCL then on SBCL.
SBCL on x86 linux (there is only 64bit linux CCL port)
Anyway, i'm using both implementation, often i choose random what to start, slime-sbcl or slime-openmcl.
Thanks both sbcl and ccl teams for great work.

[Paul Donnelly]

Paul: I think I've seen you on Stump's IRC channel, and I'm sure there are ways to get the heap size down.

Nope, never been there. Maybe I'll see about shrinking it though, I hadn't thought about that.

[tayssir]

SBCL and Lispworks. A short while ago, I shipped a project which was implemented using those two Lisp implementations.

Lispworks (Windows):

• Windows GUI for someone who needs to select things quickly and usably. The users are nontechnical and may even be nervous with the computer, so they need extra usability support. Essentially a webapp with a rich-client GUI instead of a browser, so it's constantly communicating with a server.

Lispworks' GUI system is pretty excellent. You're given a simple declarative language, much like DEFCLASS. But to start out, there's a handy graphical tool which lets you build a simple tree respresentation of a GUI, auto-generating its code. I found that it started to suck once the GUI gets more complex; at which point you'll want to make changes to the DEFCLASS-like output. (Maybe it's come to scale better since I checked.) The documentation certainly isn't Java-level, but it's fine, I think.

I'm staying at a minor version lower than the current version, because I'm not sure how to get the new one working well with Emacs/Slime I find Emacs very useful, even if maybe the debugging facilities in Lispworks' IDE is far superior.

The users opine that the GUI looks attractive. I'm glad that I don't need some bulky installer; it's all in one .exe, though I need to package a few DLLs for older Windows installations.

Pretty crossplatform. I remember building a Windows GUI, which ran on MacOS without needing to alter a line of code. I mean, I'm sure I'd have to change the menu items around to conform to the Mac's UI guidelines, but that's not a big deal.

SBCL (FreeBSD):

• website (which contains video as well as continuously-updated meeting info)
• controls a video editor (displays text and graphics under a speaker's face) and streams video to TV station
• database
• coordinates these various parts, sending serialized objects all over the place

Looking at the poll results, most of us are familiar with SBCL. On the live server, I have a screen session with 3 Emacs/Slime sessions, and one screen devoted to displaying whether video is being transmitted to the SBCL-controlled video editor.

There's 3 technical weak links:

• VLC (an opensource video server) -- I simply don't trust it. The project's constraints seemed to force the use of it. However, now those constraints are greatly loosened.
• Networking. This is largely a human problem. Who knows when someone decides to change some resource's address, or decides to stop sticking our webpages into the main site? Also, pulling video from the multicast server requires a voodoo hack. (The one part I didn't write in Lisp was a Java proxy which forwarded multicast packets to the Lisp-controlled VLC instances. It probably could've been written in Lisp; I merely wrote it in Java to eliminate Lisp as a potential culprit while solving my multicast problem.)
• Elephant/Postmodern is pleasant and simple, though I have a nagging concern about it occasionally complaining about DB connections. (Doesn't seem to lose data AFAIK; just complains.) Definitely need to fix that.

It's actually been programmed almost exclusively by one person, under suboptimal conditions.

Upcoming changes:

• Fancy video features (Flash, etc), and radical decrease in the app's dependence on VLC.
• Significant usability improvement -- instead of selecting items from a list (with the help of an interactive search box), users will be able to select 2D dots positioned like the room layout.
• In a main chamber, cameras and mics will do the user's job, for the most part, so the user can lounge around.