[tumba]

  > My advice is this: as you learn Common Lisp and look for 
  > libraries, try to suppress the voice in the back of your 
  > head that says “This project was last updated six years 
  > ago? That’s probably abandoned and broken.” The stability 
  > of Common Lisp means that sometimes libraries can just be 
  > done, not abandoned, so don’t dismiss them out of hand.

I have found this to be true in my own experience. The perception of stagnation is, however, a common initial objection to folks working in CL for the first time.

[mike_ivanov]

My personal problem with CL libraries is not that, but rather the lack of documentation. More often than not, there is no documentation at all, not even a readme file.. It feels like some library authors simply don't care. I'd say this attitude has a negative impact on how people perceive viability of those libraries -- and by extension, of the language.

[armitron]

A lot of libraries that don't have separate documentation in the form of HTML/PDF/README.. are actually well-documented at source level in the form of docstrings.

Since Common Lisp is an interactive programming language and is meant to be used interactively (think Smalltalk, not Python) it is common practice to (interactively) load a library in a Common Lisp image and explore it (interactively). One can see what symbols are exported from packages, what these symbols are used for and (interactively) retrieve their documentation. All of this takes place within the editing environment (ideally Emacs) in a rapid feedback loop (again think Smalltalk, not Python) that feels seamless and tremendously empowering.

[stevelosh]

I agree with this -- it's a real problem. My only solution has been to try to be the change I want to see in the world and document all of my own libraries before I officially release them.