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.
  • You don't think that the feeling of "no one wants to talk about problem X" and "There aren't enough people to do the work." are related?

    Or how about the barriers to entry to help out? Real or perceived I've noticed a definite feeling of "I would never deign to tell $perl_deity that $x is wrong. $perl_deity is so much smarter than me"

    • by Damian (784) on 2006.02.28 17:17 (#46377)
      I would never deign to tell $perl_deity that $x is wrong. $perl_deity is so much smarter than me.
      As someone whose specific job it is to tell Larry when I think he's wrong, I can certainly empathize with that trepidation. ;-)

      But I can also tell you that bona fide @perl_deities are smart enough to know that they're not always smart enough. And humble enough to welcome corrections when they're needed.

      The thing I've found most useful (both in telling someone else they're wrong, and in being told myself) is to do it in the right spirit and in the right tone. In particular, to be non-confrontational and specific.

      That is, instead of:

      "Your plans to make public attribute variables polymorphic are a disaster. I can't believe you're willing to wreck the entire OO model with this assinine decision! Please reconsider this egregious blunder."
      say something like:
      "I read about the decision to make public attribute variables polymorphic and I had some concerns about it. It seems to me that polymorphic attributes variables will be prone to many of the same problems that tied variables can produce. Specifically, that they introduce a risk of very subtle bugs in very common kinds of OO code, bugs that can only be found at runtime from derived classes and in unusual circumstances. For example:

      (give specific example here)

      Maybe I'm missing something obvious, but isn't that kind of mistake going to trip up a lot of ordinary programmers, who almost certainly won't be expecting covariant behaviour from a implementation feature such as an attribute variable?"

      You'd be amazed how grateful people can be when their genuine mistakes are pointed out to them in a constructive and courteous manner...especially by correspondents who recognize the possibility that the defect might not be in the idea itself, but rather in the exposition of it.
      • Here is a rule I live by that the Marines taught me. Never bitch unless you have at least two suggestions for improvement.

        • Oh neat, I specifically like the "at least 2" part.

          (adds it to his "unless you have a better way, and are willing to do the work if you have to")