[Gardeners] Project Proposal: Standardized Utility Library

[Peter Seibel]

On Jun 7, 2006, at 4:27 PM, Nikodemus Siivola wrote:

> Peter Seibel <peter at gigamonkeys.com> 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           * peter at gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp  * http://www.gigamonkeys.com/book/