Two years of Quicklisp

http://blog.quicklisp.org/2012/10/two-years-of-quicklisp.html

by wglb • 14 years ago

73 21 14 years ago

blog.quicklisp.org

leephillips• 14 years ago

I suggest placing a link somewhere that will lead me to something telling me what Quicklisp is.

paradoja• 14 years ago

It's a package manager for Common Lisp.

wglb• 14 years ago

Good point. See http://www.quicklisp.org/beta/ for download information.

Puts getting required lisp libraries in the "extremely easy" category.

prodigal_erik2• 14 years ago

From a look at http://www.quicklisp.org/beta/, it looks like another single-language tool for smuggling code onto a box while failing to set up any interdependencies with the system's package manager. I don't like being so harsh, but "every language has its own packages and none of them interop at all" is a growing antipattern that eventually leads to horrible messes.

sgrove3• 14 years ago

So write a blog post elsewhere about it. It's one I'd absolutely be interested in reading.

But posting this 'harsh' comment here is useless and detracts from useful conversation.

aidenn02• 14 years ago

System-wide package management is broken. If you want me to use the system-wide package manager, fix it.

adestefan• 14 years ago

And every system has their own package manager and none of them interop at all.

If I'm writing a CL package, a Python package, or a Ruby package, then I'd rather spend my time getting them to work in their respective language eco-system instead of working in the Ubuntu, Debian, Red Hat, Windows, OS X, FreeBSD, etc. eco-system.

kryptiskt• 14 years ago

Which is all good, because system package managers usually adds six months to two years latency to feature updates. I'd rather that the development environment have a tool for managing its libraries than I have to install them all by hand. It's a horribly broken system to have the same cadence for vital system parts and development frameworks. Running a stable system while having bleeding edge tools and applications shouldn't need to be an unattainable edge case.

klibertp• 14 years ago

Why should I bother? I have many projects on my box, each of them lives in virtualenv, each has it's own packages and all the projects are separated from themselves and the system (meaning my global, system-level python can not use any of the packages in virtualenv).

So why should tell system pkg manager about something which is not system-wide?

Also, virtualenv comes in stdlib now!

sedachv• 14 years ago

> it looks like another single-language tool for smuggling code onto a box while failing to set up any interdependencies with the system's package manager. I don't like being so harsh, but "every language has its own packages and none of them interop at all" is a growing antipattern that eventually leads to horrible messes.

I like that Quicklisp doesn't interoperate with the system package manager (I use Debian and Debian derivatives mostly). Quicklisp sets up repositories per-user, which means I can easily have different versions of libraries running for different users. This is handy because the Unix user facility is the original "virtual machine." All Common Lisp implementations are also very easy to set up to run from your home directory, which is great. I never use apt for installing CL implementations.

System packaging is great for command-line and GUI applications, and certain services like databases. But I don't think it works for development, and I don't even think that having machine-wide library installation (like npm and RubyGems) is a good idea. I've used npm and RubyGems and the way Quicklisp does things is much better in my experience (although one thing it doesn't provide is library versioning for individual projects).

e40• 14 years ago

CPAN for Common Lisp.

draven• 14 years ago

The subtitle of the blog is: "News and updates for Quicklisp, the Common Lisp library manager." so that's not too bad.

Anyway thanks to Xach for quicklisp, it made experimenting with CL libs much easier!

mark_l_watson• 14 years ago

Zach has done a great job of seeing a need in the Common Lisp community and writing a packaging system to meet that need.

I don't use Common Lisp as much as I used to but when I do I now use Quicklisp for every project.

A further benefit of Quicklisp is being able to browse available packages and quickly experiment with packages that may be useful. I think that Quicklisp tightens up this exploratory cycle.

barakm• 14 years ago

This seems incredibly useful; for someone who wants to try it out, which is a good, open-source, cross-platform CL to try it on? The example uses SBCL, but I know none of the tradeoffs.

sgrove3• 14 years ago

I've used SBCL quite a bit, and only dabbled with others, but I have no complaints about it in particular. It's amazing in what it's able to do, certainly.

enduser• 14 years ago

SBCL is perhaps the fastest open-source implementation of Common Lisp. It has incredible developers and a rich set of implementation-specific functionality. SBCL's "home platform" is Linux, but it runs on Linux, *BSD, Mac, and Windows (32-bit only for Windows at present). SBCL's native code compiler rivals C/C++ for speed when properly hinted. SBCL also has the highest-quality integration with emacs (via SLIME) and Vim (via slimv). The developers seem to expect that you will use SBCL with an editor, so the command-line REPL doesn't even have readline support. ITA Software uses SBCL to run all or most of QPX, the search engine behind sites like Orbitz and Expedia. SBCL does its own memory management and likes a large heap. Standalone executable size is large (20+MB) because it includes the compiler. SBCL is derived from CMUCL and thus has a 32-years-mature lineage and is very stable and performs very well. SBCL has excellent threading , Unicode, and 64-bit support.

CLISP is another implementation that is interpteted (i.e. not native-compiled like SBCL i.e. slower in most cases). It has a somewhat nicer REPL and debugger out of the box, and super-fast bignum support. I believe CLISP is what pg used to create Viaweb.

There is also Clozure Common Lisp (predating and not to be confused with Clojure). CCL is well integrated with Cocoa on the OS X platform and seems to be moving in the direction of ARM suport (iOS support in the future?). I have the impression that CCL may be more popular with OS X users, but I have yet to find reason to use it over SBCL on Linux.

ECL (Embedded Common Lisp) is an implementation that translates to C and uses gcc for compilation. ECL builds the tiniest executables (a couple hundred K or less) and is perhaps well-suited both as an extension language and for embedded platforms. ECL does not seem to support all of the libraries I've tried with it, but it supports enough of Common Lisp to be a viable platform for those who require its strengths.

TeMPOraL• 14 years ago

SBCL seems to be currently most popular, but if you're working on Windows, I'd encourage you to give Clozure CL a try.

Most of the stuff I did in CL was related to 3D graphics and computer games, and while SBCL has the required performance, it tends to crash on Windowses, and every other CL I tried except Clozure CL is not fast enough to even run SDL examples in real-time.

aidenn02• 14 years ago

Some of this info might be out-of-date since I obviously don't use all lisp implementations all the time:

SBCL:

* Biggest weakness: not super-well tested on windows

* Strengths: Generates super-fast code, is the most comonly targeted implementation by OSS libraries

CLISP:

* Biggest weakness: Performance

* Strengths: Fast bignum implementation, most portable of all lisps (If you have a C compiler, you can probably get it working on your platform)

ClozureCL:

* Code generated is not as good as SBCL, but compiler is considerably faster

* Better windows support than SBCL

* Has builtin support for OS X gui

Ecl:

* Currently the best if you want to embed CL in C

* Application delivery is very different from other LISPs

* Uses a non-copying conservative GC (which embedding in C easier) that just can't be as good as generational copying GCs

Two years of Quicklisp

Related Stories