in reply to Re^9: Modern Perl and the Future of Perl
in thread Modern Perl and the Future of Perl

P::C is not useful to get accustomed to a wide variety of idioms, patterns and ways of expression, because it reduces the set.... P::C isn't useful to achieve any of those goals.

You keep saying this, and I keep not understanding what you mean. What do you think there is about P::C that makes people turn off their brains and keep generating oatmeal-bland code? Is it the default ruleset (which I agree is definitely not perfect for all purposes, but is highly customizable)? Or is it the idea that someone might criticize code that's not bog-standard shop-standard baby Perl and rewrite it that way?

I've seen code reviews so nitpicky and wrong-headed that they rewrote nice Perlish for-style loops into C-style for loops and missed important things like meaningful, domain-specific names for identifiers and quality of algorithm. Those happen with or without P::C.

I agree that using it to make everyone use the abysmal if (!something...) construct where postfix unless makes more sense is stupid. I've seen people arguing for that based on PBP, and they're wrong.

However, I haven't seen anyone seriously arguing that anyone should use P::C to detect and stamp out deviations from the coding standards across the organization except you and BrowserUk, and that in the negative. That kind of passive-aggressive behavior is actually harmful to development teams, and I agree with both of you that it's counterproductive.

So I really don't understand why you say there are so many people promoting dangerous things with it, at least anyone worth listening to.

Update: Rephrased based on Re^11: Modern Perl and the Future of Perl, as I didn't write what I meant and wrote exactly the opposite of what I meant.

Replies are listed 'Best First'.
Re^11: Modern Perl and the Future of Perl
by shmem (Chancellor) on Dec 23, 2007 at 01:57 UTC
    You keep saying this, and I keep not understanding what you mean. What do you think there is about P::C that makes people turn off their brains and keep generating oatmeal-bland code? Is it the default ruleset (which I agree is definitely not perfect for all purposes, but is highly customizable)? Or is it the idea that someone might criticize code that's not bog-standard shop-standard baby Perl and rewrite it that way?

    I don't say that people turn their brains off using P::C. I say it is not useful to gain the knowledge. That is done else-wise. P::C can be used to test whether you have it, but doesn't give it, like a school test. Generalized school tests are wonderful instruments to truncate interest for a subject in children. I know, because I have gone through that hell. Then, in an older post in this thread I said

    Perl::Critic alienates what has to be a programmer's internal state into a technical instrument, which is wrong.

    What is your opinion on that particular quote?

    So I really don't understand why you say there are so many people promoting dangerous things with it, at least anyone worth listening to.

    I think I've written succinctly about the danger in my post to which your post is an answer

    I have a tank. Sometimes I use it to drag cars out of the mud. Everyone should have a tank and use it.
    and in a previous post in which I linked to the Personal Firewall FAQ.

    Employing Perl::Critic, following the rules until it is silent gives a false sense of security of having "right best practice" perl code. Not to you, not to me, but maybe to the maintainer of bugzilla, and who knows how many others. So I'm more concerned about they not turning their brain on.

    But in the end it is all about perception. While I support much of the "Perl Best Practice" content, I strongly disagree with it's title, and I object to it for the same reasons I criticize Perl::Critic. From the pod:

    DESCRIPTION
    Perl::Critic is an extensible framework for creating and applying coding standards to Perl source code. Essentially, it is a static source code analysis engine. Perl::Critic is distributed with a number of Perl::Critic::Policy modules that attempt to enforce various coding guidelines. Most Policy modules are based on Damian Conway's book Perl Best Practices. However, Perl::Critic is not limited to PBP and will even support Policies that contradict Conway. You can enable, disable, and customize those Polices through the Perl::Critic interface. You can also create new Policy modules that suit your own tastes.
    (emphasis mine)

    Enforcement of coding guidelines. How are people - not you! - taking this? To what end will they use Perl::Critic? I have a tank...

    --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}
      To what end will they use Perl::Critic?

      That really depends on what they want to accomplish. You're not going to convince me that the existence of P::C and your emboldened clause will suddenly turn good coders into raging lunatics, and you're not going to convince me that telling everyone not to use a good and useful tool because raging lunatics might misuse it is a smart idea.

      Spammers often use Perl, and Template, for example. They could use Mail::Bulkmail if they wanted. If I didn't have a mailing list manager at work, I might use it to send out the Perl newsletter.

      Perl::Critic alienates what has to be a programmer's internal state into a technical instrument, which is wrong.

      Valgrind and gdb take what could be my internal state of reading through a program, reasoning about what it does and when, and turn it into a technical instrument, and you can take them away from me when I retire from programming for good.

      Perl::Tidy takes what I could do manually -- format code -- and turns it into a technical process. Sure, someone could write a pre-commit hook that runs P::T over a chunk of code and rejects the commit if there are any variations from the coding standard. Anyone who does that is a passive-aggressive lunatic control freak though, and it's not the tool's fault.

      If you, or I, or Max K-A, or anyone shuts off your, my, his, or her brain when using P::T or P::C or strict or warnings, it's not the tool's fault, and telling people not to use the tool isn't going to fix that. People looking for shortcuts won't stop looking for shortcuts if P::C goes away, and they're not magically going to create good code and write thoughtfully and become great developers just because you've taken away one shortcut. (Believing the converse is, in my mind, a shortcut of the same kind.)

      In conclusion:

      Perl::Critic is an extensible framework for creating and applying coding standards to Perl source code. Essentially, it is a static source code analysis engine. Perl::Critic is distributed with a number of Perl::Critic::Policy modules that attempt to enforce various coding guidelines. Most Policy modules are based on Damian Conway's book Perl Best Practices. However, Perl::Critic is not limited to PBP and will even support Policies that contradict Conway. You can enable, disable, and customize those Polices through the Perl::Critic interface. You can also create new Policy modules that suit your own tastes.

      Emphasis mine. Thank you for the discussion.

        Keep fighting until you win, because you don't care about truth. By looking at you and your behavior, I not only |SUSPECT perl 6 is dead, I KNOW it is dead.

Re^11: Modern Perl and the Future of Perl
by BrowserUk (Patriarch) on Dec 22, 2007 at 20:27 UTC
    I agree that using it to make everyone use the abysmal if (!something...) construct where postfix unless makes more sense is stupid, but I haven't see anyone seriously arguing that except you and BrowserUk, and that in the negative.

    Sorry, but I just cannot let that slide. Do a supersearch for "unless" and see the people who are. advocating exactly that. What's more, doing so in threads in which you have stepped in to counter it.

    Unless you believe your interventions have completely stamped out that meme?

    Then pull up a cpan search of Perl::Critic::* and run through some of the "violations" that it "prohibits".

    Just because you (think) that you are not misusing this misbegotton tool, it doesn't mean that no one else is. Nor many someone elses are.

    You seem to think that we are telling you, that you must not use it. And exactly, only you. That is so not the case. If you, the right thinking, considerate and careful, idiom loving (where it doesn't compromise your codebase) you, find it useful, that's fine. We will not attempt to stop you.

    It's all the less considerate, less right thinking, --pbp-is-easy-to-type-so-everyone-must-use-that-verbatim, non-yous that are the target of our distaste. (I believe PBP still suggests the total prohibition of unless?)


    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.