On Sun, Feb 12, 2006 at 12:00:56AM +0100, Marc Battyani wrote: > "Tayssir John Gabbour" <[EMAIL PROTECTED]> wrote:
> > A big newbie problem seems to be evaluating programs they haven't > > learned, Problem made worse by not having the background knowledge of what else is out there, or the specific skills to learn quickly the program they're evaluating. Certainly, this the trouble I have now. > > investing time only to see the potholes which no one talks about. This can be common to many things, not just newbies, or evaluating software libraries. I think the antidotes are to note the useful parts and to take the time to construct something positive from the potholes found. Pending the round tuit for this, my thoughts on FiveAM are stuck in a private text file. 8-/ > > I think there should be a faq entry on this. My thoughts: > > > > * Currently, the best place to evaluate a package is skimming the > > mailing lists' archives, or emailing the author(s). [...] > > > > * If newbies see a serious problem with a lib, speak up! [...] I think this is standard and sensible practice. > That's rather easy: First add the package/library/whatever to the > Common Lisp Directory (if it's not already there) Adding new stuff is always good. It is what the directory needs. > Then add comments ;-) May I support contacting the author or project list first? For this reason: The CL Directory is centralised data for the seeker of code. Its purpose to make it easy to discover, overview and later download from a collection of many packages. (Have I got this right?) A project's home is centralised data for the project's maintainers and users, when they're on that thread. It has everything the project maintainer considers relevant to the project. This almost always contains a preferred way to contact the project, even if it's only "email me if you have problems". It may also include links to similar projects, user reviews and hooks back into the CL Directory. Unless the project directed them there, problem reports on placed on CLD will be outside the project's home. The comment is likely to be ignored, and then if the problem is fixed it's unlikely that this will be reported on CLD because it has already been done on the mailing list or web site. If the maintainer shares your great enthusiasm for CLD - is aware of it and uses the relevant RSS feed - he will make it part of the project's home. It might help if you say how you would like to see this done. Compiled data in directory format has always been subject to this problem of being disconnected. It is the same type of problem as those caused by copying code, then fixing the bugs in some copies. I think the most likely solution is something semantic web -like, but we don't have that yet. > So people looking for a library will get it with its associated > comments. If the comments are good for now and the future, this is useful. But what of comments made two years ago, upon an active project? Earlier in this mail I had views on potholes, so... I suppose I would like to see CLD be successful by focussing on what it set out to do, rather than get sidetracked in supplanting project home pages. If the CLD can do something better than the project home, make this a new focus and make it explicit. This gentle rant brought to you by the League of Programmers Against Duplication of Data, (for whom "data" includes code, which includes interactive websites). Matthew #8-) _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
