The Lisp library ecosystem is not as organized as that for some other languages. But, quicklisp succeeded in giving a good central point and simple access to libraries. Some reasons for the situation are historic, but some result from the fact that there is not a canonical Lisp implementation as for languages like python, java or perl. The commercial Lisp implementations (and most open source ones) ship with their own set of supporting libraries, so you are less dependent on third-party libraries to get stuff done.
But to everyone who wants to get started with Lisp, I can only recommend not to focus on libraries first. Between what the language includes (especially Common Lisp), and what the implementation ships with, you should be set up to do a lot of serious programming. If there is anything, which you cannot do with the default environment and with what you cannot implement faster yourself, then its time to use quicklisp to add the missing pieces. But having written some pretty large Common Lisp programs myself, they tend to depend on only a very few external libraries.
Seriously. I just started looking into Common Lisp last weekend, and if it weren't for the active communities on Reddit and IRC, you'd get the impression that the language was abandoned some time in 2012.
Common Lisp is a very stable language. The standard hasn't changed in twenty years, so (unlike many other languages) old code is still perfectly good. Libraries that haven't been updated in a decade still work just as well as they did a decade ago.
It's not just that standard hasn't changed in almost twenty-five years, most of it was agreed upon in the early 1980's and it was developed by consensus among a language community of working programmers and commercial interests.
This is nice to know. Do Quicklisp packages typically come with test suites? At least then I can check if a package will work before I commit to using it.
Not only do many of the do, it is common practice for release candidates of asdf, sbcl (and probably other implementations) to run those tests against release candidates as a regression test.
But unfortunately not all libraries set up their test-ops properly. You can usually find a readme at ~/quicklisp/dists/quicklisp/software/... which might have instructions for running tests.
My subjective impression regarding third-party libraries specifically is that if anything, the situation has improved a lot in the past 5 years, mainly due to Quicklisp becoming the de-facto standard. Now there's a curated collection of libraries that are tested to work across multiple CL implementations, pull dependencies properly, etc., instead of the previous mess of manually downloading .tar.gz from random places on the internet.
But if you look at Clojure libraries, some of them were last updated in 2012. That's because clojure solves problems (& it's not that the maintainers have disappeared) :)
A funny thing is: A typical response from CLers to this type of comment is "yes CL can handle large projects". There is a definition gap, though, where one imagines a project that is "large as in a company", i.e. a large project that involves many people, while another imagine that is "large as in a system", a project with a large SLOC. And they are sometimes mixed.
CL can handle a large SLOC, as evidenced by the fact that the huge compiler such as SBCL itself is written in CL. But it won't be as popular as Java or C++ are, so it would become a problem when CL faces a project which is "large as in company".
SBCL is not really that large in LOC, though it has some complexity. It's a mid-sized Lisp program with some complexity, since it implements a type inferencing native compiler with backends for various platforms. SBCL itself was derived and simplified from the CMUCL implementation.
There are some CL code bases with millions of lines. But even a million line in todays terms is not much for some companies which are using other languages. If we look back, the operating system and basic environment (GUI, IDE, basic apps) of the Lisp Machine OS was around 500 kloc. Later versions with more stuff and some applications were nearing 2 Mloc. The commercial CL companies (Franz, Harlequin/LispWorks, Lucid, Xerox, TI, LMI, Apple, Goldhill, DEC, ...) usually should have developed code bases with +1MLOC already in the 80s / early 90s. Some Common Lisp based CAD software was/is in the range of 5-10 MLoc. Some application code might be much larger. For example Boeing has whole jet aircrafts designed in Lisp using the now discontinued iCAD application.
> so it would become a problem when CL faces a project which is "large as in company".
Common Lisp has been used in environments with up to 300 developers. This is not really a large number, but a larger number of what people typically think of a Lisp project. Symbolics, the Lisp Machine company, had at max 1000 employees - with probably a third of that software developers. Lucent developed network switches in the 80s/90s with 100+ Lisp developers. ITA was developing their flight search engine with a 100+ team with a lot Lisp developers. There are also smaller companies with a long history - for example Cyc is being developed using Lisp since thirty years.
One problem was/is finding these people. An old saying was that there were more Lisp Machines than developers able to use them. Today it would be even more of a problem, since the number of interesting Lisp projects at universities is smaller than what we had in the 80s/90s. Thus fewer students get in contact.
Probably a good idea to visit the European Lisp Symposium in Brussels, April 2017. Meet some fellow Lisp users from academia, industry, ...
So one of the first recommendations on that site is for the Clack family. The first link to clacklisp.org has now started pointing to the github project. For a long while before that it was just dead.
Clack, whilst being a great concept suffers from a lack of documentation. What documentation is there is confusing. It seems Clack has in the past couple of years been split out into a separate project - Lack. There's no documentation around as to why this has been done. I can't find details on how to write middleware for it. I need to look through the source.
I'm trying to get Ningle working. The Redis session middleware seems broken. It doesn't seem thread safe at all. I seem to have other problems with by body parameters being mutated as it passes through the middleware.
I have gotten very close to just dropping Clack and moving onto raw Huchentoot or Allegro serve, but it saddens me that a project with such promise shouldn't get the love it deserves so I will probably persist and hopefully help to improve the project.
Don't get me wrong, I love Common Lisp as a language and use it daily. But problems like this are just standard.
Yeah, I am liking clack and I really need to get off my butt and write a tutorial or something for it. It's much less complicated than it looks. However, I agree that much of the middleware that ships with it is at a level I would call "Proof of concept" rather than "Production ready."
I agree about the lack of documentation being a major pain point in the ecosystem.
As far as web projects goes, this looks promising: https://github.com/Shirakumo/radiance Shinmera puts a lot of effort into finishing his libraries and documenting them well, so I expect that this library would be nicer to use than many of the alternatives.
