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 future (Score:3, Insightful)

    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

              • I agree so much with the framework comments. Successful ones evolve.

                Getting out of the framework-writing mindset and letting structure fall out from refactoring duplicate code has made my life so much easier (and improved the code a fair bit too :-)
                • 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

                • While I can't prevent a few people from misunderstanding my arguments entirely nor others from taking my words out of context to support arguments I'd never make, you do raise valid points I hadn't considered. I'll keep them in mind. Thank you.

                • 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 i

                    • Apparently you see something radically different in that title from what I see. When I see "open source developers," I don't see someone singling out open source developers; I see someone ignoring proprietary development because he and his audience could care less if they do well or not. The article title, to me, is obviously about improving the quality of open source development, not denigrating it.

                      --
                      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
                      • Also as I've said elsewhere, I should wait for the article before really passing judgement.

                      Like Alannis Morisette's song Irony says "It's the good advice that you just didn't take".

                      As I kept telling myself... I should have waited to pass judgement. The article is out [onlamp.com] and it's GREAT!

                      I'm sorry that I passed judgement based on my preconceptions.

                      It's full of really good observations, mostly stuff that really relates primarily to Open Source development, so my fear of Open Source developers being singled

                    • Like Alannis Morisette's song Irony says "It's the good advice that you just didn't take".

                      What's ironic about that song is that Ms. Morisette clearly didn't understand irony. Virtually none of the situations she discusses are ironic.

                      And yes, you apologized and I was hear to witness it. Kudos :)

                    • Actually, I don't really agree that the song doesn't express irony. It expresses what's known as dramatic irony.

                      Also, the "good advice that you just didn't take" is ironic in the rhetorical sense. It's an ironic twist on the meaning of "good advice".

                      Lastly, even if you don't think there's any "real" irony in the song, there's the ultimate irony, that you pointed out, that it's about irony but it's not.

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

              You misunderstood. The point of the article is to encourage improvements in these areas, not to disparage open source development or compare it unfavorably to closed source development.

              Programmers tell a lot of lies. Fred Brooks told us before I was born (and maybe you, too) that that's because we're eternal optimists. :)

              --
              J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
                • The point of the article is to encourage improvements in these areas, not to disparage open source development or compare it unfavorably to closed source development.

                I agree that developers tell a lot of lies, to themselves and others, but an article titled "Lies Open Source Developers Tell Themselves" certainly seems to imply that this is a problem among Open Source Developers as distinct from any other type.

                Certainly an article titled "Lies Americans Tell Themselves" would be taken to apply to lies Am

                • Certainly an article titled "Lies Americans Tell Themselves" would be taken to apply to lies Americans tell themselves that others do not.

                  Ooh, ooh, ooh! I wanna write that article. Can I, can I, huh? Puleeeeze? :)

                  • As an American you're disqualified from writing such an article.

                    If you can't be truthful with yourself, how can we expect you to be truthful about the Lies Americans Tell Themsleves?

                    Hmmm, maybe you are actually ideally qualified. Perhaps it's the case that Americans not only tell themselves lies, but like to read lies about the lies they tell themselves.

                    Didn't Al Franken just write that in book form, though?

                    • Perhaps it's the case that Americans not only tell themselves lies, but like to read lies about the lies they tell themselves.

                      That's just the thing. As an open source developer, I tell myself lies, and I like to read about them so I can start telling myself the truth.

                      --
                      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • The problem with Perl for this sort of thing is you run smack bang into the issue of the amount of cruft you need to write to get your encapsulated method up and running.

        sub is_an_admin {
                my($self, $user) = @_;
                exists $self->{admins}{$user}; # Or whatever
        }

        When you're encapsulating a one line test that's an awful lot of stuff, but if you want maintainability you just have to bite the bullet (and the performance hit). Roll on Perl 6.

        method is_an