Brad Beveridge writes: > On 12/19/05, Joshua Stone <[EMAIL PROTECTED]> wrote: > > > > > With many of the errors being an artifact of Wiseman's implementation > > choice, different implementations would generate different lists of > > errors. Packages that Wiseman successfully installed may not work on > > other implementation-platform combinations. (see the 404 error trying to > > fetch SB-BSD-SOCKETS) > > This is a good observation. I think that the matrix of libraries vs > implementations is probably the only sensible way to find the bugs. >
I agree. In fact, it would be really useful to have a matrix associated with each library listed/mentioned on the wiki so that anyone searching for a library can see at a glance if the library is supported under the implementation they favor. If its not, they can then decide to either try porting it to the implementation they use or re-implement the library functionality themselves. As an extension, we could possibly place an additional value in the matrix which shows the number of known bugs/issues associated with the library on a specific platform. We could even go a step further and have this somehow tied to a rating system as I think it will be important to have some sort of ranking of libraries, especially once we have multiple libraries providing similar/same functionality. While a lot of people have talked about how good it would be to have something like CPAN for lisp, I've always found CPAN lacking in one area (note its been some years since I did a lot of perl programming and things may have changed). The problem has been selecting which library to use. for example (real life), you are creating a perl application which uses SNMP. Rather than re-inventing the wheel, the first place you check is CPAN. On doing a search for SNMP, you find a number of CPAN moduels which appear to provide the functionality you need. How do you select one? Maybe you go on the one which has been most recently updated on the basis that it is probably the most actively maintained. However, it may actually be the one which is most poorly implemented with the most bugs and the package which has not been updated for ages is actually the best because its not needed any update. I've encountered this exact problem and initially, I made the wrong choice and had to go back and select an alternative SNMP module later (which required lots of code updates) because when a new version of perl came out, the module broke and it was not being maintained (it broke because it used version specific behavior which changed). So, what would we want in a ranking? Well, possibly, we would want some indication of the number of implementations supported, the number of general bugs, the number of implementation specific bugs, a measure of functionality, ease of use and possibly 'lispiness'. Maybe we could assign 2 points for each lisp implementation supported, -1 point for each general (non-implementation related) bug, -0.5 for each implementation specific bug, and average of all scores out of 5 for functionality, an average of all scores for ease of use and an average of scores for 'lispiness'. Just a very rough 'stream of consciousness' suggestion which may get others thinking/inspired. Tim _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
