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.

In reply to Re^12: Modern Perl and the Future of Perl by chromatic
in thread Modern Perl and the Future of Perl by chromatic

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.