[pro] Langutils

[Zach Beane]

Erik Huelsmann <ehuels at gmail.com> writes:

> Hi Zach,
>
>
>> > 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.
>
> Do you also see a role for cl-test-grid here, which tests quicklisp
> packaged libraries on a large number of platforms and may thus provide
> potential users with the insights they need for their platforms?

Yes, very much so. It would be good to know, at a glance, that some
library has been tested already and is known not to work on your chosen
platform. 

It would also be helpful to make that information fairly detailed, on
further clicking, so you can make in informed decision about how
accurate it might be (how recently was it tested?), and what work it
might take to get it to work, or at least to the next failure point.

For example, if some project fails to build on SBCL because it uses the
LispWorks MP package, someone could see that and decide to try updating
it to use bordeaux-threads instead. That might lead to a working
project, or it might lead to a new failure, but at least it's some basis
for making a decision about what to do.

Zach