Two years of Quicklisp | Hacker News Reader

Two years of Quicklisp

blog.quicklisp.org

73 pointswglb21 comments

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.

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

It's a package manager for Common Lisp.

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

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

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.

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.

Seen complaints about startups which are obviously saving passwords in plaintext? Imagine how much worse it would be if all the "why you shouldn't it that way" criticism was consigned to obscure blogs rather than here. I regard this as that kind of problem--huge long-term drawbacks that people don't proactively go looking into and don't immediately deter implementing the idea.

If you want something done then you need to start on it yourself. Disregarding what QuickLisp has accomplished because you have to deal with more than one package management system is trollish. You'll probably want to start by designing a plugin framework that can support multiple versions of any given language. Also need to be able to bundle dependencies per application, on any operating system, so that you don't pollute the global package space for any one given application under developement. kthx

That seems better reasoned - you could expand on it and explain why this is a problem, how it should be avoided, how language packages should be integrated with system packages, etc. That would make for very interesting reading.

I'm wondering if a 'new' age of sysadmin is coming along that will basically build a vm-image of an application node, with the OS built using chef/puppet/etc, so that the host packages are as few as possible. Just a thought.

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

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.

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.

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!

> 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).

CPAN for Common Lisp.

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!

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.

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.

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.

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.

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

Reply on news.ycombinator.com