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.
  • The issue I run into day-to-day is building in hooks for future needs. You don't want to build code that can't be easily modified, but nor do you need a plug-in framework based on future conjecture.
    --

    --
    xoa

    • There's also an open source myth in there somewhere. (I should be writing that article, not eating a candy bar and reading use Perl;.)

      There was a discussion on Perl Monks today about access checking. The poster just needed to check if a given user name is in the list of admins. That's pretty simple: just a hash look up.

      While I normally use exists to avoid autovivification issues, one poster claimed that that was bad design. "What if you add administrative levels in the future and one of those levels

        • There's also an open source myth in there somewhere. (I should be writing that article, not eating a candy bar and reading use Perl;.)

        I wish you would just write the article, rather than continuing to cast aspersions in the direction of open source. It's hard to address a lot of vague notions.

        Whatever you write, I doubt that there's any problem in open source that I can't find in closed source, as well. Prima Donna developers? I've seen many working on Closed Source projects. Bad code? Believe me, s

        • You're barking up the wrong tree [oreillynet.com]. He's not putting down open source developement, but (like many of us in the open source community) he is interested in how we can improve.
          • I know who Chromatic is and I recognize his Open Source credentials.

            I guess I overreacted to the teaser [perl.org], where he said:

            I've decided to write a new article entitled Lies Open Source Developers Tell Ourselves. Here's a brief list of untruthy topics: feature freezes, competing projects, popularity, packaging, documentation, frameworks, rewrites, and code quality.

            Which seems to paint Open Source Developers, as a group, as being delusional with regard to a number of important issues.

            While there may be some p

            • Andy's comments about frameworks precipitated my comment.

              I now believe very strongly that trying to build a framework is almost always a mistake. Compare successful frameworks and toolkits (GTK, APR) to unsuccessful ones (Mozilla's GRE, Worldforge, lots of things coming out of the JCP or even the W3C these days). The successful ones all grew out of existing successful projects and were generalized to work with other projects. The unsuccessful ones were designed as frameworks and haven't really met the