Funny, I did quite a deep dive on this same issue about two years back, and came to exactly the opposite conclusion: keep ASDF, and lean on Nix to do pinning. I now maintain my own Common Lisp package repository, testing daily against nightly SBCL etc, and I've learned that a lot of CL stability is just because test suites are never run. Nix goes a long way to shield me from the haphazard breakages that other commenters mentioned, but of course it comes with a huge downside: you need to use Nix :)

(just kidding)

Code at https://github.com/hraban/cl-nix-lite if someone is interested.

Obviously since this was written by Fukamachi you know it will be good. Much respect to the man.

This is great news. The updates to SBCL broke some libraries (that is, sbcl got more thorough in finding bugs that some libraries had) and I've had to load patches in for them because of the quicklisp limitation in a patch file. This will make life much simpler as do all of Fukamachi's libraries in general. (His internet suite is fantastic)

I bet my money on https://github.com/ocicl/ocicl

Edit: as much as love fukamachi - but still

Seems like an attempt to bring "lockfiles" or related concepts to Quicklisp. This is a desperately needed quality-of-life improvement for "modern" Common Lisp development.

However, I wish people in the Common Lisp community weren't weary of using ASDF directly. It already supports versioning and many features that do not exist in Quicklisp -- despite the fact Quicklisp wraps ASDF -- such as a package that depends on a version of a library newer (or older) than what exists in the current dist.

It's kind of impressive that Common Lisp is the only language I use where I can't expect code written today to work next month due to Quicklisp lacking versioning outside of the date attached to dists.

Those who still use Common Lisp or some variant of Lisp (other than Clojure), what's your reasoning behind choosing this language over the more mainstream options? I understand that Lisp has some powerful features, but almost everyone that I've talked to holds reservations for those.

For example, Lisp macros are amazing. BUT... this is not good for communicating code in big teams.

Or live (image) programs are an interesting concept, but git versioning them is much more difficult than traditional source code versioning.

Or hot code reloading, which sounds like a powerful concept except that companies would rather log and document their codebase. It also makes it challenging to keep track of the state.

If you force teams not to use macros, then a great reason behind s-exps goes away. And in general, if you take these features away from Lisp, I'm just not sure what use case Lisp can serve.

Love me some Lisposting. Keep it up fellas