Discuss and learn Lisp programming of all dialects
This is a read-only archive of lispforum.com. The forum was locked to new users and
posts and is preserved here as static HTML from a database snapshot taken on
2019-09-07.
Poll: Which Lisp implementations do you use?
33 posts · 50646 views
Which Lisp implmentations do you use the most? (choose up to 2)
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.
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.
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.
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.
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?
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.
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.
findinglisp wrote: 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.
I do use ABCL! It's a good implementation, and having the JVM as target is actually very good.
I also use XCL (the, er, non-official other Lisp from Peter Graves).
Why, for example, use XCL? I actually test my software with all implementations but two. I really want it to be portable, and testing with all implementations help spot small/subtle bugs in my software. (Some implementations may not complain or misbehave, but others will, so it's best to run through all of them).
The two I don't use are Scieneer (only available if you pay) and Corman (I gave up fighting its GUI)
The two I use most are SBCL and Clisp. Both have excellent debugging support, and SBCL is very fast.
Am I correct that the main reason that Corman CL is overlooked is due to the instability of it and Win32 only? I've been helping Roger systemmatically identify and flush out some of the remaining GC bugs. The fact that Corman is so trivially embeddable into a Win32 app, has decent performance, and a good FFI in an affordable package is too sweet. I'm writing a video game with it, and the app is definately CPU bound, so clisp doesn't seem to be a good option.
Am I correct that the main reason that Corman CL is overlooked is due to the instability of it and Win32 only?
I can only speack for myself; I don't use it because I never really liked its user interface, and I use Linux primarily. I see that SLIME has support for Corman, so I suppose I could install Emacs on my Windows box and give it a try.
I'm a newbie writing a roguelike game in Lisp, and while I develop it in Clisp (under windows), eventually I plan on releasing it as stand-alone packages on some systems (Windows and Linux at least) - I'm not sure if I want it open source, and Clisp's license would force me to do that, so I guess I will look into ECL.
humpolec wrote:I'm a newbie writing a roguelike game in Lisp, and while I develop it in Clisp (under windows), eventually I plan on releasing it as stand-alone packages on some systems (Windows and Linux at least) - I'm not sure if I want it open source, and Clisp's license would force me to do that, so I guess I will look into ECL.
Note:
This copyright does NOT cover user programs that run in CLISP and
third-party packages not part of CLISP, if
a) They only reference external symbols in CLISP's public packages
that define API also provided by many other Common Lisp implementations
(namely the packages COMMON-LISP, COMMON-LISP-USER, KEYWORD, CLOS,
GRAY, EXT), i.e. if they don't rely on CLISP internals and would as
well run in any other Common Lisp implementation. Or
b) They only reference external symbols in CLISP's public packages
that define API also provided by many other Common Lisp implementations
(namely the packages COMMON-LISP, COMMON-LISP-USER, KEYWORD, CLOS,
GRAY, EXT) and some external, not CLISP specific, symbols in
third-party packages that are released with source code under a
GPL compatible license and that run in a great number of Common Lisp
implementations, i.e. if they rely on CLISP internals only to the
extent needed for gaining some functionality also available in a
great number of Common Lisp implementations.
Such user programs are not covered by the term "derived work" used in
the GNU GPL. Neither is their compiled code, i.e. the result of compiling
them by use of the function COMPILE-FILE. We refer to such user programs
as "independent work".
It looks like at some point one of the libraries you use would need to be GPL-compatibly licensed, perhaps your graphics library, or perhaps only an FFI wrapper like CFFI, and that only if said library relies on CLISP-specific features. IANAL.
From what I understand from the license, distributing a modified binary would require me to distribute either source code or FAS files along with them, and making FAS files available isn't hiding the implementation very well.
I'm pretty sure CLISP's license doesn't force that. From http://clisp.cvs.sourceforge.net/*check ... /COPYRIGHT :
<<snip...>>
It looks like at some point one of the libraries you use would need to be GPL-compatibly licensed, perhaps your graphics library, or perhaps only an FFI wrapper like CFFI, and that only if said library relies on CLISP-specific features. IANAL.[/quote]
The short of it is while you can write a program with CLISP that isn't covered by the GPL, to do so, you pretty much have to stick to the standard Lisp API and avoid anything CLISP-specific. This means that for any practical program, CLISP is not a viable alternative if you want to avoid the GPL.
IMO, this is a big issue with CLISP. One of the biggest things that has helped propel GCC as the "standard" C compiler is that it doesn't force programs written with it to be GPL-compatible. IMO, languages and runtimes need to separate their own licenses from that of the code that is produced with them.
That said, CLISP is one of the two implementations that I use. It's greatest strengths are its supreme portability and rich set of extensions. It's a shame that those are marred with a viral GPL.
Also, please note that I'm not anti-GPL. I currently work for an open source company (http://www.vyatta.com) that releases its code under GPL. I simply believe that programmers should have choices and separating the language implementation license from the license of programs released with that language implementation leads to better outcomes for both sides.
Paul Donnelly wrote:
I'm pretty sure CLISP's license doesn't force that. From http://clisp.cvs.sourceforge.net/*check ... /COPYRIGHT :
<<snip...>>
It looks like at some point one of the libraries you use would need to be GPL-compatibly licensed, perhaps your graphics library, or perhaps only an FFI wrapper like CFFI, and that only if said library relies on CLISP-specific features. IANAL.
The short of it is while you can write a program with CLISP that isn't covered by the GPL, to do so, you pretty much have to stick to the standard Lisp API and avoid anything CLISP-specific. This means that for any practical program, CLISP is not a viable alternative if you want to avoid the GPL.
My reading yields "stick to the standard and cross-platform libraries", which doesn't sound so bad. But I agree, it's confusing, and I'm not sure I'd want to risk getting legally tangled in it.
It varies, but lately I have mostly been using Allegro and Scieneer, with some CMUCL.
I share your concerns about the CLISP license situation. The thing that would particularly worry me is that the reason CLISP is under the GPL is because it uses GNU readline. (See http://en.wikipedia.org/wiki/CLISP, and follow reference 1.) Because of this, it's not clear to me that Haible even has the right to modify the terms of the GPL.
sburson wrote:I share your concerns about the CLISP license situation. The thing that would particularly worry me is that the reason CLISP is under the GPL is because it uses GNU readline. (See http://en.wikipedia.org/wiki/CLISP, and follow reference 1.) Because of this, it's not clear to me that Haible even has the right to modify the terms of the GPL.
Well if that's the case, can't they just rip out libreadline (or replace it with libedit or something) and then do what they like with the license? That is, of course, if they want to change the license.
Wodin wrote:can't they just rip out libreadline (or replace it with libedit or something) and then do what they like with the license? That is, of course, if they want to change the license.
It's true. Maybe they've done that; I haven't checked. But if they have, and if they want CLISP to be usable in commercial products, I think they should just switch to the LGPL and eliminate the confusion.
sburson wrote:I share your concerns about the CLISP license situation. The thing that would particularly worry me is that the reason CLISP is under the GPL is because it uses GNU readline. (See http://en.wikipedia.org/wiki/CLISP, and follow reference 1.) Because of this, it's not clear to me that Haible even has the right to modify the terms of the GPL.
Well if that's the case, can't they just rip out libreadline (or replace it with libedit or something) and then do what they like with the license? That is, of course, if they want to change the license.
Not necessarily, because they might not have full copyright over the whole of CLISP anymore. If they have taken GPL contributions from outside contributors, that makes things sticky. Technically, they'd have to have agreement from each of those contributors. I don't know how many of those they have or whether its feasible to contact all of them. This is essentially the same issue that the Linux kernel has.
If they were clean and got copyright assignment from every contributor, they can do as you say and change the license without issue. Most open source projects aren't that clean.
Wodin wrote:can't they just rip out libreadline (or replace it with libedit or something) and then do what they like with the license? That is, of course, if they want to change the license.
It's true. Maybe they've done that; I haven't checked. But if they have, and if they want CLISP to be usable in commercial products, I think they should just switch to the LGPL and eliminate the confusion.
Just thought I'd note: Red Hat and SuSE Linux are commercial products.
Slightly snarky to state the obvious, but misnomyrs get started small.
Wodin wrote:Well if that's the case, can't they just rip out libreadline (or replace it with libedit or something) and then do what they like with the license? That is, of course, if they want to change the license.
Not necessarily, because they might not have full copyright over the whole of CLISP anymore. If they have taken GPL contributions from outside contributors, that makes things sticky. Technically, they'd have to have agreement from each of those contributors. I don't know how many of those they have or whether its feasible to contact all of them. This is essentially the same issue that the Linux kernel has.
I have heard the argument that Linus could in fact change the license of the Linux kernel without necessarily contacting every single developer who has ever contributed code to the kernel. I can't remember where I read that article, though. As far as I remember the author said something like Linus would have to announce the intention to change the license and then give copyright holders the chance to object. For the ones that object, obviously the code would have to be ripped out and rewritten. For ones that just never responded, you could act as if they had said yes.
I am not a lawyer, though, so I'm not sure how true that is.
TheGZeus wrote:Just thought I'd note: Red Hat and SuSE Linux are commercial products.
Slightly snarky to state the obvious, but misnomyrs get started small.
Yes, I suppose "proprietary" would be a better word to use.
Wodin wrote:
I have heard the argument that Linus could in fact change the license of the Linux kernel without necessarily contacting every single developer who has ever contributed code to the kernel. I can't remember where I read that article, though. As far as I remember the author said something like Linus would have to announce the intention to change the license and then give copyright holders the chance to object. For the ones that object, obviously the code would have to be ripped out and rewritten. For ones that just never responded, you could act as if they had said yes.
I am not a lawyer, though, so I'm not sure how true that is.
Hmmm... I would definitely want to talk with a lawyer about that. There may be standard procedures for some of that, but everything I have read about copyright law says that it's a really big PITA to clear copyright when you have lots of people involved. And even a small copyright holder can throw a wrench in the gears.
If you're interested in this sort of thing, check out Lawrence Lessig's Free Culture. Very highly recommended. It goes through all the problems with copyright law. The Creative Commons was created by Lessig to help deal with some of the problems he sees in the laws. Ideally, we'd change the laws, but as the book lays out, there are powerful industries that don't want to see that happen (the RIAA, MPAA, Disney, etc.). To be honest, I don't blame them. When your whole company is based on the original copyright to Mickey Mouse, you would not be doing your fiduciary duty to your shareholders if you let that unravel. That said, the current laws are pretty much unworkable. Everything these days is automatically copyrighted for the lifetime of the author plus something like 75 years. That means that essentially every created work is off limits "forever" unless the author explicitly says otherwise. Consequently, there are a lot of works that are not currently being used that could be reused, reissued, reprinted, etc., but the author can't be found to give permission to do so. Lessig makes the point that in the culture by its nature builds on top of culture and if we make all this raw material "off limits," the culture of the future will be very sterile, without any continuity, because it will have to be created afresh each time with few inputs from the past.
Anyway, I didn't mean to go sideways in this thread. If you're interested in copyright and these issues, check out the book.
I guess it's worth noting that the reason I use SBCL is that as for a relative newcomer to Lisp it is more accessible than many other implementations. I think many folks like a nice syntax highlighted IDE to work in. It didn't take me long to find the Eclipse/CUSP combination and CUSP uses SBCL by default (with SLIME). This made it easier to get productive quickly. I know, Eclipse is a lumbering giant but it's intuitive for those not steeped in Emacs. The last thing I wanted to stack on top of learning a new language was learning a new editing strategy.
I just tried out ClozureCL on Linux-x86 (from trunk), and I like it so far. Compiler is fast, the code produced in reasonably fast, smaller initial image than SBCL. After loading McCLIM and the demos, ROOM showed it was using only ~28 megs (while SBCL would use ~56 megs).
The output from some of its functions/macros seem a bit busy to me, and trying the Logic Cube demo from McCLIM causes it to quit, but otherwise nice.
Really late edit: I said the compiler is fast; now it seems to be even faster under 32bit linux; I'm scared how fast it compiles McCLIM and all of its dependencies...
I just got my Lispworks copy installed so i couldn't resist to coming here and changing my entry to include this one now. Basically it will be SBCL on Linux for Web/Server stuff and Lispworks for desktop.
I'm using ECL and SBCL on Windows. I'm favoring ECL, but would probably choose SBCL for anything with non-trivial performance goals -- right now, I'm just learning Common Lisp and prototyping.
At ITA Software, we use SBCL for one large project, and CCL for one even larger project. One constraint at ITA is that we are committed to using open source implementations. We switched from CMUCL to SBCL somewhat before I joined the company (three years ago). These two implementations are closely related, but SBCL has several improvements. We use Linux exclusively.
The reasons for using SBCL on one product and CCL on the other are rather complex and involve things like differences of opinion within ITA, which I'd rather not talk about in public. Both implementations are excellent. One important advantage of CCL is that the compiler runs very quickly, which is very helpful for compile-edit-debug cycles that cannot be done incrementally, including running complete system tests. Also, we currently get very good information from the debugger for CCL, whereas when I was last using SBCL, it was not as good (I don't know how much it might have been improved since then).
We also feel good about the fact that CCL is maintained by an actual company with full-time employees who are dedicated to improving the product. SBCL is maintained by an informal group of maintainers, who work on SBCL on their own time, or when they are engaged as consultants. Let me emphasize that the SBCL maintainers include some truly excellent developers, and I don't inten to be disrespectful to them.
The product that uses SBCL (QPX) is very compute-intensive, and we believe that SBCL's compiler generates faster code for this application. Actually, the standard Gabriel micro-benchmarks don't say that either of these implementations is across-the-board faster than the other. Micro-benchmarks have many limitations, and can't be relied upon to predict the relative performance of real applications.
I find Emacs very useful, even if maybe the debugging facilities in Lispworks' IDE is far superior.