[pro] Langutils

[Zach Beane]

Nick Levine <nick at nicklevine.org> writes:

>> It doesn't seem so obvious as to where to find who might have
>> unpicked this already. Or find documentation behind a system and its
>> design intent. I.e. although perhaps nothing should be in Quicklisp
>> unless pure and solid, it can be quite a goose chase to try to hunt
>> down remedies when that does not seem the case.
>
> I don't _think_ it's Quicklisp's concern to ensure how well things
> work, only that loading one doesn't break another. Some QL libraries
> come with test-suites, and others do not. 

Your thought is correct. When wearing my Quicklisp dist maintainer hat,
I do not judge the quality or necessity of a library. If someone submits
a library to Quicklisp, and it builds, I add it. (In some circumstances,
I do ask the submitter what might distinguish a library from the many
similar libraries already availble, but even then I do not reject the
library.)

> But I agree that library quality / support are important parts of
> library discovery: if you don't know which ones are generally thought
> of as good, or which ones have an active support network, how can you
> ever choose between them? Solving the library discovery problem is
> probably rather people-intensive, which I imagine is why nobody's done
> it. I'm told other languages suffer from this too.

I think quickdocs.org helps. I would also like to see some mechanism for
incorporating user feedback (e.g. "I tried this library on LispWorks and
it keeps crashing" or "The documentation doesn't match the code any
more" or "This is great, it solved my problem and it's really fast") and
rating. Building such a thing would take a generous expenditure of time
and effort, so I understand why it hasn't popped into existence already.

Zach