On Mon, Dec 11, 2006 at 01:08:46PM -0500, Ryan Davis wrote: > I agree that this is a matter of community organization. There are > several libraries out there to accomplish this, but there isn't any > momentum behind any one of them. I think this is due to the > individualistic tendencies of lisp programs and programmers, but I think > there are enough people interested in doing Real Work® that we should > just pick some packages and start writing tutorials. Instead of > creating a cl-batteries project that combines other libraries, I think > what is needed is an index of comprehensive tutorials, which just needs > more blood and sweat than code.
It seems to me that the obvious answer is a simple one: 1. work on documentation 2. pick one of the already-existing efforts and throw unified community support behind it > > I think the main usefulness of the python docs is that the information > is centralized, not that its one dependancy. A python programmer knows > they want to send an email, so they go to that page and find "email" and > are on their way. The lisp programmer wanting to send an email needs to > find and evaluate a number of competing libraries that might be what > they want. Right now much of the lisp tutorial information is scattered > through cliki, cl-user, cl-cookbook, blogs, mailing lists, irc logs, > clhs, and others I'm forgetting. For example, searching cl-user for > "email" finds cl-pop, core services, and rfc2822. Searching for the tag > "email" reveals cl-http, cl-smtp, cl-pop, mel-base, and rfc2822. More > choices are confusing for users who just want a functional solution to a > common problem. I have much more interest in a documentation project > designed to answer questions like "how do I send an email" than another > meta-package to combine libraries. I think the meta-package would > follow naturally after a critical mass of tutorials are written/linked to. This reads like an exhortation to pick one library for each general purpose, and only promote that -- sort of a reimplimentation of the Python "one good way to do it" philosophy. I personally think that's a mistake, because sometimes a different good way to do it is better. A number of different ways to do something means you can have the best way for your specific needs at any given time. Instead, what I think would be the best option is to make an effort to create unified documentation that organizes not only by library, but also by desired functionality. For instance, while each library should of course have its own documentation, there should also be documentation with a label such as "sending email" that discusses all the commonly available libraries that provide such functionality, and compares the characteristics of these different libraries so that people who want to send email via a CL application can make an informed decision without having to build half a dozen versions of the application and testing them all. In other words, documentation organized to match the needs of those reading it is important, and would greatly enhance the ease of Getting Things Done. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] Amazon.com interview candidate: "When C++ is your hammer, everything starts to look like your thumb." _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
