Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • I am kind of sceptical when it comes to people doing a lot of CPAN distributions. There's a pretty long way from an idea of a possible CPAN module to its implementation. For a reasonably complex module, this can take months with all the documentation and tests, interface-considerations etc. And that's only the first step. It has to be maintained afterwards

    Essentially I have a few unfinished modules lying around. My most ambitious project was probably porting the Aalib to Perl. I was mostly done with it (ev
    • My reply is remarkably old, so I apologize, but I feel I must clarify my original statements.

      Basically, I'm not spinning out CPAN modules for the hell of it; I can't tolerate "Hero Coding". On the other hand though, my modules were very small and, to me, seemingly inconsequential ones. Maintaining them has been very easy, mainly because there isn't much to go wrong.

      My original intention of this journal entry was to say that most of the code I've written could have been abstracted to a CPAN module, but wasn't. Instead of writing software with an eye towards reusability and "What might other developers use this for?", I would write code in a vacuum. So instead, I've begun spending extra time on my projects to build my code in a reusable fashion. If, after a few months, my module has matured and is still usable to me, I release it to CPAN. As it is I've only added one extra module to CPAN since this journal entry, but I feel it was worth the effort.

      I have two other modules that I'm using at work which are still sitting on the sidelines, mainly because I don't think they're ready for public use yet.
      -man Michael A Nachbaur