To all - I've changed the original subject. I hope this doesn't bother anybody too much.
This is a well-worn discussion. The last time this was thoroughly discussed was on the porters list: see the porters' archives starting from October 31, 2009, and running into November. These are from the days when I spent a lot of effort stirring the pot, and a bit less at actually writing code. [Note: November 2009 has one of the largest collection messages in the archives, and my pot stirring has been bested by no less than the great Daniel Carrera, whose ability to stir a pot (and get docs and code written) still impresses me.] I have since repented my lack of code writing and I've tried hard to focus more on writing code and less on stirring pots. If you don't believe me, just wait for PDL::Graphics::Prima. :-) Back in late 2009 when we last discussed this, nearly everybody was in favor of splitting PDL into multiple pieces. Judd Taylor voiced a dissenting opinion, stating that PDL needs to have a large collection of numerical capabilities built-in so that it appeals to new folks. If people have to install lots of modules to get what they want, they'll just walk away. He also claimed that the lack of an install-everywhere 2D plotting library was a big issue. Read his email and others' responses to get a fuller picture: http://mailman.jach.hawaii.edu/pipermail//pdl-porters/2009-November/001617.html These days, I stand by my original statement, that PDL would be best served split into many smaller pieces. BioPerl underwent a similar transitions a few years ago, and many major frameworks (Test comes to mind) were built like this from the ground up, providing a simple core upon which others can build. We are a Perl technology, and I believe we would do well to embrace the current trend in Perl modules to provide simpler distributions that target specific goals. I see two issues: 1) Quality Assurance. Whenever somebody makes a change to the core, they run the *whole* test suite. If we split the core, changes made in one component will not be easily tested against other components. Solutions include (1) CPAN testers, which should be able to pick out bad interactions within a few days to a week, and (2) a continuous integration server specifically for PDL. For the latter, jitterbug, a Perl-based continuous integration system comes to mind. It would be amazing, it would take time to set up, and it would cost $$ to host the server unless somebody out there has a box sitting idle on a static IP. (Lately I have been thinking about purchasing a $7/month VPS for this very idea, and for hosting the IRC bot.) 2) Knowing where to find things. If we split things up, we must have documentation about where to find information about different PDL capabilities. This is all the more important if users are installing PDL, and need to know what to install. Installation itself is becoming much easier with local::lib, perlbrew, and the Alien packages (shout out to Joel for his recent work on Alien::Base). The current docs are not very tied together and may not give the user and idea of where (in monolithic PDL) where to look, but they do have an Index document that knows about all the installed modules. The solution to this is simple, but hard: write better docs that make thorough references to what's out there. I believe that the benefits greatly outweigh the costs, but the greatest missing piece is commitment by PDL porters and users to make it happen. Back then, I began working on Module::Build::PDL, but I lost steam when I was told that M::B::PDL would have to build the entire PDL distribution. I have since figured out that what I had accomplished with M::B::PDL can be as easily achieved using Module::Build with well crafted .pm.PL files. My opinion is now this: if we can't achieve our split of PDL into pieces that M::B can handle, then the pieces are still too big. So, here's what I say: let us kvetch! We will move forward with 2.4.10 and the close follow-up of 2.4.11, but everybody should lay out their thoughts about splitting up PDL (or not). After the dust has settled, as 2.4.11 is taking form, those us of who are truly interested can re-read the discussion and decide how to move forward. In particular, I would *love* to send out another survey, this time asking about what people want and *how many hours people are willing to commit to make it happen.* David -- Sent via my carrier pigeon.
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
