Peter Seibel <[EMAIL PROTECTED]> writes:
>> 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.
And whether you believe your users have it. And whether you trust
that next upgrade of the library will or will not add new symbols
that conflict with your names.
I think there are two separate issues here:
* trust in conservative maintenance. (Of course, if you version the
packages UTIL.<release> or whatever that is a lesser consern.)
* getting the mudball out there in strength. I tend to think it
is easier to start with a pound of mud then a ton of mud... ;-)
>> 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.
Well, sort of. But then you just get their code, but may well miss
their custom.
>> ...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.
Reading what I wrote again, I should underline that I ment that a fair
share of the aforementioned projects should be _users_ of this
mythical mudball for it to be part of the landscape. Not undoable,
but more of a social feat then technical -- though there are some
technical issues too, certainly.
> 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
That was what I ment, yes.
> 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.
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.
> 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.
(Without looking at the docs.) I'd say that it is pretty good. Not
a spec in the real sense of the word, since AFAIK that is "be perl
compatible as long as it is sane", but pretty damn close -- close
enough that turning it into "a real spec" is not a nightmare.
> 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.
Right. But sometimes less _is_ more. I think that one of the problems
is that once you expand upon the basic Common Lisp you have so many
valid and good ways of coding -- which means that to cover the common
ground that you can end up with an uncomfortably large namespace.
That's why I think it can be helpful to set a few stakes in ground
saying "we're not going to go there, not now at least".
> 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.
Definitely. I've done a few sketches for wannabe standard libraries,
and I always stopped when I saw how HUGE they were getting without
doing anything fancy. And since different people and differaent
projects use different things in concert, splitting up the namespace
in a way that doesn't end up requiring most people to USE most of
it... that can be quite challenging.
As a techical note, it may very well be that a proper mudball is
better IMPORTed from then USEd. Just a thought.
> 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.)
Sufficient documentation is indistinguishable from a specification. ;-)
I have hard time thinking of a documentation that wasn't close-enough
to specification that I am really happy about. If it isn't specified,
how do I know what it does? Telepathy and guessing don't count. :P
> 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?"
Bedtime,
-- 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
