On Jun 7, 2006, at 4:27 PM, Nikodemus Siivola wrote: > Peter Seibel <[EMAIL PROTECTED]> writes:
[snip] > Right. While the technical work may be greater in the end, I think > getting the intellectual buy-in from projects with their own > utility libraries is where real work lies initially. > >> What do you think we should talk to library authors about? My guess > > "Hi, we're building a standard library for Common Lisp. We noticed > that you projects FOO and BAR have utilities X, Y, and Z, which > we will also have. How would you feel about depending on our > library instead? If you'd rather not, why not, and what could > we do about it?" Well, as I've said before, it's a lot easier to agree on something than to agree on how to agree about something. By which I mean, I think the surest way to doom a project is to have step 1 be, "Get buy- in on some abstract notion or process from a bunch of people with quite different motivations." Either it will flounder forever because nobody wants to buy into something before they see what it is and of what value it will be to them or people will give their "buy-in" too easily and when push comes to shove we discover that no one really meant it. Much easier (though still requiring a lot of work) to actually put something together and then say, how can we make this better? I think Ian, et al. (which, again, includes me) should start putting together a collection of libraries and making sure the whole ball of mud can be downloaded and used easily by the average newcomer to Lisp. It may be the case that that will mean there is a certain redundancy in the ball of mud as library X will have it's version of A, B, and C and library Y it's own versions. But that doesn't really matter--we don't have to document every bit of functionality that happens to live in the ball and at least the whole thing will be vaguely usable. Then we can work on making the ball of mud more attractive (better and/or more uniform docs/specs for the included libraries), rationalizing the packaging (in the CL PACKAGE sense), fixing bugs, whatever. So far none of this requires buy-in from the authors of existing libraries--it's our job to make sure their libraries work in this context. If there are bits of redundant utility code down in the center of the mud ball it doesn't matter. I think library authors will get involved when they either start writing libraries that themselves use the "standard" libraries we are gathering or when they start contributing libraries directly to the project. Both of which I think will happen when enough users are using the thing that those are worth doing. Somewhere far down the line we can worry about cleaning up the internals of the thing so there isn't quite so much redundancy. Anyway, that's my take on how it could work. In the end, the success or failure of such a project is going to depend far more on whether a small group of people is willing to do the work necessary to make it happen than any other factor. -Peter -- Peter Seibel * [EMAIL PROTECTED] Gigamonkeys Consulting * http://www.gigamonkeys.com/ Practical Common Lisp * http://www.gigamonkeys.com/book/ _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
