Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^7: Best practice or cargo cult?

by TheDamian (Priest)
on Jun 25, 2006 at 12:16 UTC ( #557425=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^7: Best practice or cargo cult?
Re^8: Best practice or cargo cult?
by shmem (Canon) on Jan 28, 2007 at 20:47 UTC
    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}

      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.
        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.

        /sm ...superdot, multianchor

        cheers --stephan
      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.

        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.

        It's when the terms 'guidelines' & 'rules' become interchangable or indistinguishable, that the problems start.

        Perhaps this will help:

        THE NATURE OF LAW 41

        In the traditional formulation, courts are required to discover law rather than invent it. In recent years this formulation has come under attack, as presupposing a Platonist ontology, and it is well to put the matter less metaphysically. Clearly we could commission the courts not to waste time giving reasons for their decisions, but to hand down their decisions more expeditiously, with occasional notes about what their policy is going to be for the future. This is the natural practice of administrative tribunals, headmasters and College deans; and it is noteworthy that as the Supreme Court of the United States of America has taken over the functions of a legislature, it has showed signs of being more concerned to make rules for the future than to determine the law actually existing at the time. But in so far as this is done, law ceases to be the common property of all citizens and becomes, instead, merely the rulings of the government; and much of the recent resentment against the Supreme Court is due to an obscure sense that it was putting itself above the Constitution, instead of being under it, like everybody else, and concerned, like everybody else, only more authoritatively, to work out what it meant. Only if the interpretation of the law is guided by reason can we all join in, and regard it as a common possession and bond of unity between us all.


        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
Node Status?
node history
Node Type: note [id://557425]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2014-08-22 23:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (168 votes), past polls