[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reasons for withdrawal
> Bradd W. Szonye wrote:
>> Why is that natural? Why the rush to publish the naming conventions?
>> Do you expect people to beat you to the punch and publish
>> incompatible collections? Do you expect people to rush out and
>> publish collections that conform to your naming standard?
> Do I expect people to write incompatible collections? No. Do I expect
> people to start publishing conforming ones? Maybe. Assuming all
> other things are resolved, there's no reason to hold it back.
Stand-alone naming standards almost always fail unless there's an
enforcement mechanism to mandate use, and finalization is wholly
inappropriate for naming standards, which must evolve with use in order
to remain usable. How do you plan to address those major issues?
While your optimism is admirable, you're largely ignoring the advice of
two QA experts who are trying to warn you of major problems, and you're
even ignoring the advice of the SRFI process itself. That's not a good
sign -- it strongly suggests that you're too eager to release the
document whether it's ready or not.
You'd do much better to follow Tom's advice: Start something like a
Sourceforge project, use SRFI-44 as the initial naming standard, recruit
developers to design and implement good concrete collections, use them
in a few real projects, and then SRFI the results. At that point it
really should be a rubber stamp, and the product will be *much* more
beneficial to the Scheme community.
Meanwhile, keep an eye out on CLS and similar forums for people who are
trying to reinvent your wheel, and bring them on board to reduce
duplication of effort. *That's* a good way to manage this project.
Now, you may not have the time to manage that and see it through to
completion. That may seem like a problem to you, but honestly I don't
think it's a good idea to submit a SRFI unless you're willing to see it
done right, through to the end, or you're willing to hand it off to
somebody who can complete your work. In addition to the other things
I've mentioned, you'd do well to read up on "egoless programming" --
while it's great to be the guy who gets the job done, it's even better
to see the job done right.
Bradd W. Szonye