(This is a repost of an old blog post of mine from Teknik. This blog post was split into multiple parts to accomodate for Movim's size limitations; use hypelinks in the table of contents to navigate.)

Are there serious open source efforts to modernize documentation?

defaultxr

Yes. You may be interested in the Common Lisp UltraSpec project.

Aidenn0

Yes, the CLHS is not available under a permissive license, but the original specification (technically final draft specification) is. One effort I'm aware of is here.

phoe

Yes - the effort started by me is Common Lisp UltraSpec that has been rather stagnant for the last few months as I've been busy with other projects and so-called real life. But, the projet is somewhat lively despite its slowness.

Hexstream

There's a modern CLOS MOP rendition project underway. Unfortunately this thread is the best thing to link to about this right now, but I think it's very relevant to the question.

Are there serious open source efforts to modernize libraries?

defaultxr

There are plenty of people working on new libraries for Common Lisp. There are also projects to update older libraries. For example, there was recently a big fundraiser to update McCLIM, a native Lisp GUI toolkit. The fundraiser was successful and there have been regular updates posted by the leader of the project about the progress being made.

lispm

You might want to clarify this a bit.

As a possible partial answer to your question: CL code has a tremendously long 'shelf life' when compared to "modern" languages. Because of the standard, code written tens of years ago or more will, more often than not, work just fine, assuming it was written for a lisp that conforms to the standard. External dependencies of course change, so ymmv, but the code will be no less correct because of its age.

alcahd

Change happens slowly in the Lisp world, but at least part of that is because it's much older than other language families and many of those software design practices were already tried decades ago. Sticking with Lisp helps inoculate you against some of the more illusionary change in other languages, i.e. parading features that were already well known in the 80s.

phoe

Why modernize them? Are they broken or outdated? If they need maintenance, why not call it "maintaining them" instead of "modernization"?

A part of why Common Lisp as a language is beautiful is that portable Common Lisp code written 20 years ago is expected to work in exactly the same way in contemporary Common Lisp implementations.

Hexstream

In a way, any libraries that are in Quicklisp can be said to have a certain level of "modernity", as at least they're guaranteed to use ASDF, the current de-facto standard build system. They've at least been passingly looked at and built by someone in the last ~7 years, which given the relatively slow-moving Common Lisp ecosystem, is in some ways not that long ago. Although not all Quicklisp libraries may be actually suitable for use, for most people it can generally be assumed that any libraries that have been around for a while and are not in Quicklisp probably need some updates and can probably be ignored.

Are there efforts to encourage open source contributions?

phoe

One specific thing I know: some projects, such as McCLIM, have set up bounties for solving identified problems and lacks within their codebase.

Aidenn0

common-lisp.net exists largely for this purpose.