Re^11: Modern Perl and the Future of Perl

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}

Comment on Re^11: Modern Perl and the Future of Perl

Replies are listed 'Best First'.
Re^12: Modern Perl and the Future of Perl by chromatic (Archbishop) on Dec 23, 2007 at 02:46 UTC
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.	[reply]
Re^13: Modern Perl and the Future of Perl by Cop (Initiate) on Dec 23, 2007 at 03:00 UTC
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.	[reply]