Peter Seibel <[EMAIL PROTECTED]> writes:
> My understanding of what Ian was proposing was something more like
> what you talk about below: a Standard Library that gathers together
> the many bits of code that are available out there and packages them
> up in a uniform way, possibly available as a single download. The
> whole point--again as I understand it--is exactly *not* to have a
> bunch of separate packages but rather a big ball of mud that includes
> a bunch of stuff so that everyone else can just say, "Get version
> 1.2.3 of the CL Standard Library and a compliant Lisp implementation
> and you can run this code."
Right. But the big problem with mudball libraries is that they
tend not to get used in a reasonable proportion to the effort
put in.
Why? Because when you need two 5-line utilities you prefer to
write them out to avoid the dependency! And because you don't
want IF* in your namespace... ;-)
How to get around this? By getting buy-in from _other_ libraries,
and then taking their needs _and_ the personal quirks and phobias
of their authors into account, so that they will be happy to
use cl-lib instead of rolling their own.
The end result is compromises all around, and probably a few bruised
egos -- because FOO did not go in (everybody hates it), because BAR
was called BAZ instead, and because QUUX did go in. (Sound familiar,
anyone?)
...but if the important stuff used by Ediware, CLSQL, UCW, McCLIM, and
whatnot goes in, other libraries will be able to think of the mudball
of power as part of the landscape, and not just another dependency to
worry about.
I really really wish this project to succeed, but I also have a
feeling of an impending trainwreck. Lots of requirements geared
towards polish, not simple reliability (a clean spec for a utility is
gazillion times more important then friendly documentation, and
somewhat more important then tests -- IMO at least), lots of things
that are IN scope, but no clear delineation of what is NOT in scope,
lists of core-operators that have been mentioned look more like
personal favorites then those most used by the big libraries (just an
impression, I haven't checked, really).
Then there is CL-UTILITIES, which certainly seems to have the best
intentions. How is this project different? From where I stand, the
difference is that CL-UTILITIES has code... (Why don't I use
CL-UTILITIES? Not sure. Partially, I think, because they aren't
sufficiently conservative about their namespace and specifications --
while EXTREMUM and ONCE-ONLY in the same package may be ok, I really
don't want an EXTREMA that doesn't do what it should (return the
smallest and the largest)...) I know, sometimes I am a stiff-necked
pedant.
Ooops. Getting into rant-mode here, sorry.
Sorry for the negative tone, too. I mean it, but not really, if you
know what I mean...
To summarize: I think that in order to succeed a standard library
needs to answer the needs of other libraries, not users. Also, in
terms of policy, specifications are paramount, as is specifying what
is out of scope. Cookbook documentation is the _least_ important bit.
Do I get to vote? +1 for intention and bravery, -1 for current plan.
Cut down to size, talk to library authors, come back with a list of a
dozen or three of operators to put in the library, be willing to leave
controversial stuff out in the first iteration, license it under
1-clause BSD or MIT, and I'll make it a resounding +1, and promise to
use it, include it with Steel Bank Studio, and pitch in.
Cheers, and good luck,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners
