On Jun 7, 2006, at 2:26 PM, Nikodemus Siivola wrote: > 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... ;-)
Well, that depends on whether you already have the mudball or not. > 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. Or you can simply (assuming compatible licensing) include their library in the mudball, and over time tweak it so the mudball isn't quite so lumpy. > 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. Yes, this should be the goal, IMO. > 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). While I too see many ways this could turn into a yet another mudball that goes nowhere (which may be what you mean by trainwreck) my guess is that depends a lot more on whether Ian and the other volunteers (which includes me) are willing to actually do a bunch of work. Personally I care less about clean specs than the basic usability of the library. Does CL-PPCRE have a clean spec or simply clean documentation? I'd say docs but if that's what you mean by specs then I'm with you. > 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... And perhaps not much else ... I think the key to this project is a mindset among the folks working on it that it's not just enough to gather up some code and hope the world starts using it. We must get together the code and the when the world *doesn't* just start using it, continually figure out what we need to do next to increase it's popularity whether that's writing better docs, incorporating more libs, improving quality, putting up a better web site, or whatever. > (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. I too think that namespace stuff is very important. The advantage of a sufficiently ambitious ball-of-mud project is that's one of the things you can try to fix by taking existing code and reorganizing the packages into some kind of sane schema. > Ooops. Getting into rant-mode here, sorry. No worries--so far this strikes me all as reasonable caution. > 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. Maybe I'm not getting what you mean by specifications--how does that differ from clear documentation? (Specification, to me, implies something documented in such a way that multiple parties can implement it. Which doesn't seem at all important for this project.) > Do I get to vote? +1 for intention and bravery, -1 for current plan. Anybody can vote. Only a few votes count "officially". And even those don't count for much. > 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. What do you think we should talk to library authors about? My guess is that there's plenty we can do without a lot of coordination effort. I'd much rather see Ian start by collecting some libraries into a common version control repository (on c-l.net or wherever) and see what we've got. One interesting question is if we start by gathering up a few of the most useful libs (cl-ppcre, etc.) and then collect the transitive closure of all the libraries they depend on, what do we end up with. -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
