Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^6: Best practice or cargo cult?

by Juerd (Abbot)
on Jun 21, 2006 at 23:42 UTC ( [id://556795]=note: print w/replies, xml ) Need Help??


in reply to Re^5: Best practice or cargo cult?
in thread Best practice or cargo cult?

Concensus requires much more than any single person...
Starting at page xx, PBP lists over two dozen other people

My remark was meant as a linguistic one, but I can see it can be interpreted in multiple ways.

It is, however, incorrect to imply that those guidelines aren't the result of extensive consultation, collaboration, and collective experience.

I never meant to imply that. My apologies if it did appear that way.

Still, I do wonder if defaulting to /msx is concensus or the opinion of a few. I've certainly never encountered many people expressing this opinion before PBP came out.

Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

Replies are listed 'Best First'.
Re^7: Best practice or cargo cult?
by TheDamian (Vicar) on Jun 25, 2006 at 12:16 UTC
    Still, I do wonder if defaulting to /msx is concensus or the opinion of a few. I've certainly never encountered many people expressing this opinion before PBP came out.
    Like many good--and bad!--memes, it certainly seems to have started with one person (i.e. me). Like you, I had never seen anyone else suggest permanent /xms until I started using it.

    But I do think that the idea has spread rapidly and is become a consensus best practice, not simply because it's Damian who advocates it, but because many people are finding it valuable, finding that it improves their coding and simplifies their maintenance.

    Of course, that's not to say that there aren't some people who do just blind adopt it because I said so. I'm sure there are such cases. Unfortuately, there's nothing I can do about that. I spent most of the first chapter of PBP pleading for readers to assess, consider, try, and then critically evaluate my advice, but not everybody has the will, the interest, the time, or (frankly) the capacity to do that. For those that don't, at least they're blindly adopting a convention that works, that is consistent, that is less error-prone than the Perl 5 defaults, that has few drawbacks or downsides, and that many more clueful Perl folks agree is a good idea and have adopted themselves.

    I fully accept that other clueful Perl folks, such as yourself, don't like the convention, and find it annoyingly constraining or less expressive or fun-diminishing. However, I'd point out that in many development environments there are good and valid reasons to restrict the freedom, expressiveness, and playfulness of individual developers, not the least of which is that not all developers in the environment are sufficiently flexible, literate, or self-disciplined to cope with the freedom, expressiveness, and playfulness of their more accomplished colleagues.

      Of course, that's not to say that there aren't some people who do just blind adopt it because I said so.

      The sad fact is that being called Best Practices these hints of yours you have outlined in a book will not blindly be adopted by skillful coders (push ikegami's home node button), but they will be enforced by others that don't have any clue about perl - our PHBs and project managers.

      If soemeone like TheDamian, and oodles of other skillful people, call them Best Practices, they must be, and heeded, right?

      Unfortuately, there's nothing I can do about that. I spent most of the first chapter of PBP pleading for readers to assess, consider, try, and then critically evaluate my advice, but not everybody has the will, the interest, the time, or (frankly) the capacity to do that.

      No, you can't do anything about that, now that the book is out. The opportunity was in considering the title of that book. Had you given it a title like Perl 5 Pitfalls (and how to avoid them) it's success would not have been less, but it wouldn't beget the nefarious consequences it does now. IMHO Best Practices is wrong because there aint "best" - all practices depend on context.

      For those that don't, at least they're blindly adopting a convention that works, that is consistent, that is less error-prone than the Perl 5 defaults, that has few drawbacks or downsides, and that many more clueful Perl folks agree is a good idea and have adopted themselves.

      If the Perl5 defaults are so error prone, then why on earth didn't you work to change them in the perl core rather than publishing a book about your view of "best defaults" and calling them "best practices"? I mean, each and every Perl 5 default has it's history and reason, and calling them implicitly Bad Practices is no service to Perl.

      Many skillful perl coders have become skillful (amongst other things) by falling into traps, gotten hurt and bitten, and by finding out why that happened they found enlightenment. The Monastery guards plenty of those stories. And so,

      I fully accept that other clueful Perl folks, such as yourself, don't like the convention, and find it annoyingly constraining or less expressive or fun-diminishing.
      those that went the hard and rocky way will have to fight convention, they will have to defend their findings and ways, simply because there's an authoritative "Best Practices" book.
      However, I'd point out that in many development environments there are good and valid reasons to restrict the freedom, expressiveness, and playfulness of individual developers, not the least of which is that not all developers in the environment are sufficiently flexible, literate, or self-disciplined to cope with the freedom, expressiveness, and playfulness of their more accomplished colleagues.

      Restrictions are each development environment's own business. IMHO, "Best Practices" dosen't improve in any way any developer's self-discipline. Self-discipline (as the word says) cannot be imposed from outside. And bottom line - anybody dealing with Perl 5 has to know TIMTOWTDI and constantly learn and will love Perl's pitfalls and dark corners - or they just chose the wrong language. You can't make perl safe and easy by turning it into a subset of itself. Any development environment that doesn't balance highly and lower skilled people is a pain anyways. Your book does not change that. Though conceived with good intent, it may turn out to be the blueprint for a Perl Procrustes Bed (in fact, it already begat such a thing - see Perl::Critic).

      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
        If the Perl5 defaults are so error prone, then why on earth didn't you work to change them in the perl core...

        Backwards compatibility.

        I'd really like to say more, but I really shouldn't have to.

        they will be enforced by others that don't have any clue about perl - our PHBs and project managers.

        In the absence of PBP, clueless managers wielding arbitrary rules with little technical knowledge would wield arbitrary rules with little technical knowledge. That's the thing about justifying stupid rules--they don't need good reasons. They'll do it anyway.

        Meanwhile, capable people have one more tool and one more book to read to gain more knowledge--knowledge that some of us learned the hard way.

        I'm fairly bad with power tools. I'm also fairly glad that the people who came before me put safety guides on bandsaws. Yes, I know they don't prevent all accidents, but I have all of my fingers and toes today because the people who knew using power tools better than I did not only taught me how to use them well but helped put rules and guides in place in the hopes of preventing me from misusing them.

        I fail to see how that's a bad thing, or how people determined to do the wrong thing no matter the cost or justification make the existence of those rules and guides bad either.

        Having upvoted this several hours ago--it strikes a cord with several of my recent posts--I got to thinking about it a little more.

        When developing a regex, I generally type m[]msx automatically. Long before I get around to deciding what goes inside the regex. I've been doing this for a long time. I think that an appropriate supersearch of my posts would turn up instances that use this, that long predate the advent of PBP. From memory, these would include several instances where I was castigated for using /s and/or /m on regexes that ultimately did not need these options.

        I do this because I've found that it makes developing the regex easier. Using /x allows me to space out the elements and spread them over several lines which is easier to read. It also allows me to comment out chunks of the regex and then uncomment them one at a time, which helps me track down which part is preventing matches.

        With /s & /m, despite that when I read the documentation their function and purpose is very clear to me, I always have to think hard about which is required to enable what, when I'm in the process actually writing regexes. It's simply easier to enable both and not get distracted from my purpose, than constantly decide which is appropriate, or is no longer appropriate, as I try out different possibilities of achieving my goal.

        Enevitably, they often get left in place once the regex is working, regardless of whether they are actually required for the final regex or not. That is, unless I have cause to go back and consider the efficiency of the regex, in which case I may well opt to remove /x which is known to slow regexes by a measurable margin. Under the circumstances where I might consider removing /x, I will usually also try removing the other two. I tend not to reason about whether they are needed, I simply try removing them and if the testcases still work, I leave them off. If not, I put them back one at a time until it does. Crude, but simple.

        And that why I make a distinction between the book, with it's set of guidelines--things to consider, along with their supporting arguments; and the module with it's unreasoned, automatic, blind enforcement of those guidelines.

        As a tool, that allows me to force me to (re-)consider my choices, it's probably valuable. But used by others to blindly enforce a set of pedantic, capricious and sometimes arbitrary laws upon the code I write, it would be completely unacceptable unless the default behaviour pretty much mirrors the 'normal' settings of Perl with warnings and strict enabled.

        There are probably a few extra warnings that could be enabled by default--though if there are, one wonders why these aren't a part of the standard warnings produced by the compiler. But anything beyond that should need to be specifically enabled, not disabled.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://556795]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others sharing their wisdom with the Monastery: (4)
As of 2024-03-19 10:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found