Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I don’t consider it an unfortunate aspect of its history that CPAN is crufty. All successful large systems start as successful small systems – organic growth is directly correlated with success. In effect, all big systems have some measure of cruft, though some more so than others.

    I am highly skeptical of a push to rebuild CPAN from scratch in an integrated fashion. There are a lot of moving parts involved, and each of them is complex in its own right, so it would take a very long time –

    • I don’t consider it an unfortunate aspect of its history that CPAN is crufty.

      Neither do I. Any large system that hasn't grown organically is going to have deep flaws. All I'm interested in is taking a step back, looking at how we've grown, and maybe considering growth in a slightly different direction.

      I am highly skeptical of a push to rebuild CPAN from scratch in an integrated fashion.

      I would be, too. That's not what I'm suggesting, nor planning to do, nor hoping anyone else will do. Especially no

  • it is 'the' primary, and mostly the only, reason people using perl have remained instead of migrating to ruby or other technologies. Perhaps the only thing that makes perl unique and special is CPAN. People too often forget this and stupidly think that over-engineering it, like p6, will be a revolution in newness and functionality. The road is littered with bodies of the puppy dogs of enthusiasm unleashed every year about this time after the conferences are over and are eager to tackle a 'big problem' only

    • Perhaps the only thing that makes perl unique and special is CPAN.

      I disagree. I think that the CPAN is a part of the larger culture surrounding Perl, and that this culture is the reason Perl is unique and successful. (I also happen to believe that the roots of this community lie partially in the design of the language itself, but that's a different musing.) The people continuing to work in, on, and around Perl are what keep it alive.

      I've kept up with the 6PAN conversations

      Wonderful, I hope I'll be able

  • You can't avoid back-compatibility. You just can't.

    CPAN is so central to the success of Perl 5 that even Perl 6 won't break back-compatibility.

    So let's forget about that right now.

    Large changes are also very tricky.

    There's some small things we can do, in fact we've been experimenting with them in the JSAN implementation.

    Things like:

    - Multiple Indexes

    - Mirror Validation and HTTP-centric rather than FTP-centric transport

    There's also plans from the Win32 side of things like a GUI failure-reporting CPAN client.
    • You can't avoid back-compatibility. You just can't.

      Well, the incompatible syntax of Perl 6 will be doing that anyway. The fact is, there will eventually be code on the CPAN that perl 5 cannot run.* If we do it very carefully, we can use this opportunity to do some really nice things for those Perl 6 modules.

      But apart from things currently being brokenish (which we can blame more on CPANPLUS, Module::Build and Module::Install)

      Wouldn't it be nice to have an infrastructure where we could have all those with