A Road to Common Lisp

tumba 57 days ago [-]

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 57 days ago [-]

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 56 days ago [-]

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 56 days ago [-]

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.

— A Road to Common Lisp

— Hacker News

.

.

2018.10.24 Wednesday ACHK