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

                • Andy's comments about frameworks precipitated my comment.
                  I now believe very strongly that trying to build a framework is almost always a mistake.

                I guess I will have to wait for the article as I'm confused now. Andy (an Open Source Developer(TM)) explicitly [perl.org]
                eschewed building frameworks when he said:

                but nor do you need a plug-in framework based on future conjecture.

                So, will your polemic include exploding the myth that Open Soure Developers tend to become involved too heavily in building frameworks? O

                • So, will your polemic include exploding the myth that Open Soure Developers tend to become involved too heavily in building frameworks? Otherwise, I don't see how you could respond to Andy's post with " There's also an open source myth in there somewhere."

                  The original journal entry was about XP myths. The poster didn't mean there was anything wrong with XP; he just meant that there are some often misunderstood things about it. In the same way, the assertion that there are open source myths doesn't mea

                  --
                  J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
                    • The original journal entry was about XP myths. The poster didn't mean there was anything wrong with XP; he just meant that there are some often misunderstood things about it. In the same way, the assertion that there are open source myths doesn't mean that's something wrong with open source; just a set of misunderstandings that need to be corrected.

                    I'm sorry, but an article that accuses Open Source Deveopers, as a class, as lying to themselves and listing a number of topics that they are less than truthfu

                    • As I said, maybe the myth that's being addressed is that Open Source Developers involve themselves in frameworks overmuch and that they like to themselves about doing it.

                      Yes, that's exactly it. We like to build frameworks for the sake of building frameworks. I think that doesn't work as often as we seem to believe it does, given how often we do it. Andy and I (and probably Ovid) have seen the same thing trip up XP shops, too. It's not limited to the open source community.

                      Oh, and I think the most important word of the title (as for the implications it has on the tone) is "ourselves".