Hacker News Reader

Comment by weavie | Hacker News Reader

I wish there was a tutorial on how to navigate through the endless sea of broken and undocumented third party libraries.

View on HN

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.

That's around when Clojure passed CL and started drawing interest away from it.

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) :)

Passed CL in buzz & hype, no doubt, but certainly not in power & suitability for large projects.

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".

Blub Advocate: CL isn't suited for the enterprise! Have you ever seen a CL project scale to a team of 100 developers?

CLer: Your language isn't suited for the enterprise. You need a hundred developers to do what we do with five.

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, ...

http://www.european-lisp-symposium.org/editions/2017/

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.

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.

Yes, almost certainly, except very fresh new libraries.

Typically yes. You should be able to run the test suite through ASDF. For example

    CL-USER> (ql:quickload :trivia)
    ... loads ...
    CL-USER> (asdf:test-system :trivia)
    ... test output ...

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.

You can also check out cl-test-grid[1] and its results[2]. It shows every quicklisp library tested against every (?) CL distribution.

[1] https://github.com/cl-test-grid/cl-test-grid [2] https://common-lisp.net/project/cl-test-grid/library/

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.

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.

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.

Lisp has always been like that. Seriously, always.

This might be helpful http://eudoxia.me/article/common-lisp-sotu-2015

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.

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.

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."

Please do!

Reply on news.ycombinator.com