Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^8: Best practice or cargo cult?

by shmem (Chancellor)
on Jan 28, 2007 at 20:47 UTC ( [id://596986]=note: print w/replies, xml ) Need Help??


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

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}

Replies are listed 'Best First'.
Re^9: Best practice or cargo cult?
by chromatic (Archbishop) on Feb 03, 2007 at 03:21 UTC
    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.
Re^9: Best practice or cargo cult?
by BrowserUk (Patriarch) on Jan 29, 2007 at 03:28 UTC

    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

        It's not what they do. It's whether whatever I just added to the regex requires one, the other or both. Or whether what I just deleted cos it didn't work means I should remove, one the other or both. It's just a distraction.

        But they are nice pnuemo... newmo... nuemonics ;)


        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.
          A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2024-03-19 04:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found