I gave a talk at ELS 2015 in London in April about the past, present, and future of Quicklisp. The “future” part detailed several things I’d like to accomplish before removing the beta label from Quicklisp.



The slides and script of the talk are available on github. But since there are over a hundred slides and about twenty pages of script, I thought I’d summarize things in this post.

First, what’s Quicklisp for, anyway? The slogan I put in the talk is: Make it easy to confidently build on the work of others. (Also, work on as many Common Lisps on as many platforms as possible.)

Quicklisp achieves part of that already. It runs well on almost all Common Lisp implementations on all platforms. It’s easy to install, use, and update. Things are tested together so everything usually works. But if something breaks on update, you can revert to a previous working version. And with those features you can build on hundreds of libraries already.

If it can do all that, why not drop the “beta” already? There are still a number of things that I want Quicklisp to do before I’m ready to say “Here, this is what I had in mind from the start.”

First, I’d like to improve the confidence in the code you download and run. By adding HTTPS, signature checking, and checksum validation, you can be sure that there is nobody intercepting and modifying the software provided by Quicklisp. The signature and archive integrity checks must be made complete and automatic to have the best results.

Second, I’d like to add comprehensive user and developer documentation. For users, that means being able to learn each command, feature, and behavior of Quicklisp, to be able to use it to its fullest. For developers, that means being able to build your own solutions on a Quicklisp foundation without starting from scratch.

Third, I’d like to make it easy to find the project that does what you need, evaluate its quality and popularity, and find out if its license is compatible with your goals. If you want to make changes to a project, I want it to be easy to get the original source of a project and send fixes or improvements to the upstream maintainer.

Fourth, I’d like to make it easy to hook into the archive-fetching component of Quicklisp in a way that makes it easy to support additional integrity checks, support local development policies, and add local mirrors or caches for Quicklisp software.

These changes and improvements will take time. When they’re done, I’ll be happy to drop “beta” from Quicklisp.