There is one important thing not covered in the book: https://www.quicklisp.org/
Quicklisp was first published in 2010 and is a library manager for Common Lisp.
Quicklisp was first published in 2010 and is a library manager for Common Lisp.
On the other hand Quicklisp has serious issues:
+ Minimal if any documentation of internals.
+ A substantial chunk of the codebase can only be described as spaghetti code. To make matters even worse, most functions lack documentation strings. A sad state of affairs given the interactive and self-documenting nature of CL.
+ Is vulnerable to man-in-the-middle attacks since it verifies neither certificates nor checksums. This means that using Quicklisp can get you owned. Unacceptable these days.
+ Operates over a 'curated repository' model that Xach is managing. The repository has been found to be vulnerable to man-in-the-middle attacks in the past since packages were fetched over plain HTTP or git://. Even if that wasn't the case, it's yet another element in the chain of things to trust.
+ Few if any people besides Xach are working on quicklisp-client to mitigate these issues. Lack of documentation and spaghetti code is not helping to attract new talent.
+ Xach is employed by Clozure Associates. I understand that they've allotted him some time to work on Quicklisp while on the job, but it's still a side-project. Look at the number of open issues at Github. Many have been there for years.
For these reasons, I don't use Quicklisp myself. I also advocate against it to friends and colleagues who share my views on software distribution mechanisms.
If I had to guess however, I would say that the vast majority of Quicklisp users are not aware of the tradeoffs they are making. It's troubling that none of the security implications I mentioned are listed or even hinted at, in the Quicklisp site https://www.quicklisp.org/beta/release-notes.html or anywhere in the Quicklisp documentation.
One alternative is to improve Quicklisp. I don't want to be seen as blaming Xach here, but he's solely responsible for the lack of documentation. For CL docstrings especially, their absence is unfathomable for a core project that is positioned for wide usage. Every function, method and dynamic variable should have a docstring. You don't add these after the fact, you add them when you're writing the code.
If Xach improves the documentation situation, people will step in and start fixing issues.
That said, the patches I sat down to do would re-use native executables (md5, sha1) and wget/curl.
One can donate for Quicklisp work, even for specific features:
https://www.quicklisp.org/donations.html
Xach is working on a fundraiser effort to get it out of beta.
https://twitter.com/quicklisp/status/798316176082354176
> To make matters even worse, most functions lack documentation strings
It's not that there are no documentation strings. Example:
https://github.com/quicklisp/quicklisp-client/blob/master/qu...
> I also advocate against it to friends and colleagues who share my views on software distribution mechanisms.
It would be better to advocate to friends to help improve it.
At the end of the day it's the quality of documentation that matters. He did document some of the generic functions but in manner that is not very productive, as the doc strings are both minimal and don't let you get an idea of how the thing fits in the overall picture.
I would bet money even Xach would be confused going back to that codebase after a year of non-exposure.
I spent an afternoon trying to figure out how to add cryptographic checksum verification support. One could say the simplest of tasks. After a few hours of diving into that codebase, a picture of the whole was not emerging. Eventually I gave up in frustration. This is not ideal.
The core of Quicklisp is in dist.lisp. Understanding the protocol of the generic functions at the start of that file will help clarify Quicklisp as a whole. Almost everything else Quicklisp does is in support of that protocol.