On Thursday, 31 January 2013 at 17:05:50 UTC, Andrei Alexandrescu
wrote:
On 1/31/13 10:38 AM, Don wrote:
The basic problem is that there are hundreds of potential
numeric
algorithms and data structures of equal importance to these
ones. In
fact, the total number of mathematical algorithms is probably a
substantial fraction of the total algorithms in computer
science!
Even a module which contained only FFT, could be quite large,
once it
included all the important related transforms.
A possible solution would be to make std.numeric a knot for
several others, or convert it to a package.
I'm not sure that we can solve this without addressing the
high-level
question: What is the scope of Phobos?
How big will it eventually get? Twice its current size? Ten
times? A
hundred times?
I think the current trend is to go for large libraries.
Both SmallPhobos and LargePhobos are reasonable, but we do
have to pick
one. Currently we have aspects of both approaches, but they
aren't
compatible.
LargePhobos. Agreed that we need to package-ize some of the
current modules.
Andrei
Another consideration is the process for a package to become
"standard". Current practice is to implement a package and go
through a review in this forum. That's a good thing, but I'd like
to see a more interactive approach, where the community was
involved sooner:
1. A package is proposed for future inclusion in the library.
Presumably this is done by someone with an interest in the
subject, ideally this is someone who wants to spearhead the
effort and may already have a draft implementation.
2. If there's enough interest to move forward, community members
could bicker about all the bikeshed stuff: structures, methods,
implementations, API, etc. until there's enough agreement about
what the result should look like.
3. Interested parties could collaborate on the implementation and
release.
4. There would have to be time limits. Many (most?) D projects
start with a bang but then fizzle out before they're complete.
There would need to be (monthly?) progress reviews. If the
discussion or the implementation has dwindled, a reconsideration
of the project could occur. If unsuccessful, the project would be
moved off the active list. If there is renewed interest or if
somebody else wants to take a crack at it the previous work can
be a resource, but the project should probably go back to step 1.
You all see the problem with this: the very short attention span
of the D community. But we've got a good start between the DIP
process and the review queue. The only thing really different
would be the progress reviews, which would hopefully prevent
projects falling of the end of the earth.
This is just one possibility and there are probably better ways
to do this. But I think some sort of maintenance of active
projects is needed.
Paul
