Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: The Most Essential Perl Development Tools Today

by BrowserUk (Pope)
on Jan 02, 2013 at 01:36 UTC ( #1011196=note: print w/ replies, xml ) Need Help??


in reply to The Most Essential Perl Development Tools Today

Perl::Critic

Would you submit to having your code reviewed by a committed of Java theoreticians?

Because that is exactly what you are doing by submitting yourself to PerlCritic.

Fully 95% of Perl::Critic's (and by implication PBP) justifictions are as puerile as banning ball games from school playgrounds because participants might skin their knees.

Making their own mistakes and learning from them is how kids learn. Banning every construct and idiom, that might under some obscure circumstances cause the occasional program to fail, is like trying to wrap your kids in cotton wool. Overindulgent, counter-productive and ultimately futile.

Like the boy that cried wolf; perlcritic prematurely bellyaches at the merest hint of a possibility of trouble. And in the process, renders programmers that obey it, to a set of rule-driven automatons that never gain experience; lack any kind of innovation; and ultimately never acquire the programmer's greatest attribute: common sense.

Many will say (have said) that perlcritic is "only advisory". The problem is that unless you have acquired the experience of when the particular constructs and idioms that it decries voluminously with artificial & fictional reasoning, are useful & not; dangerous & not; perfectly acceptable despite their dangers, & not; you will never have the knowledge upon which to reject its advice. Or not.

Perlcritic is the thin end of the wedge to the de-skilling(*) of the programmer's art. Reject it. JUST SAY NO!

(*Look up that word. Learn from the history that underlies it. Remember the old fart's of today were yesterday's youth. And do not deceive yourself into thinking that the youth of today know anything; think anything; or try anything that their forebears didn't know, think or try 20 years before them. Those that ignore history are bound to repeat it.)


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.


Comment on Re: The Most Essential Perl Development Tools Today
Re^2: The Most Essential Perl Development Tools Today
by Tommy (Chaplain) on Jan 02, 2013 at 05:14 UTC

    I love it. The dissenting opinion... and it's a good one. You've made a very good case here. I have to take this into account; you've persuaded me a bit, and I think some changes are necessary.

    Thank you.

Re^2: The Most Essential Perl Development Tools Today
by pemungkah (Priest) on Jan 02, 2013 at 22:51 UTC
    And I'll disagree, but just a little.

    There are mechanical I-should-probably-always-do-this things that Perl::Critic can check for:

    • Did you use strict and warnings?
    • Did you remember to use 3-arg open?
    And several other things that Perlmonks repeatedly urges people to do that are on the mechanical side, meaning that they are simply "did I remember to do this or not?" questions that are not syntactically or semantically invalid, but are reasonable standards to enforce on your code. If the requirement to do something is mechanical, then making the check to see that it is done mechanical is reasonably well-advised.

    I do not currently run Perl::Critic against our codebase, but I can see that there are some - some - checks that might be useful - the "did I remember" ones. I do completely agree with BrowserUK that running all of the checks and just doing everything it says to do is very much the wrong way to go, mostly because you're abdicating your own judgement and knowledge of the code to something that does not actually understand the code at all.

    Used as a to-do list specifically for what you want to remember to do, and adapted to your particular needs, Perl::Critic is pretty useful. Otherwise, it's like a to-do list that includes the things that someone else has decided people Should Do.

    Metaphorically speaking, if you have a busy 20-something single woman living in Brooklyn and a forgetful 80-something man living in rural Arizona, the Brooklynite doesn't need a reminder to shake scorpions out of her shoes, but it might be critical for the Arizonan. Perl::Critic by default reminds you to be careful not to be mugged for your phone, but has no idea that scorpions even exist.

    (Okay, to stretch the metaphor, it's actually warning you to not be mugged for your Walkman because it's never heard of cellphones.)

      Used as a to-do list specifically for what you want to remember to do, and adapted to your particular needs, Perl::Critic is pretty useful.

      Sorry. But that "you can configure it to your needs" argument simply doesn't hold water. Let's start with the extremes:

      1. The experienced. Perler.

        When PC (thos initials say it all :) first came around, I ran it out-of-the-box against several scripts and modules -- some my own; some by authors I respect and trust -- and it just bugged me intensely.

        It whinged and whined and cried wolf about every other line of code. The only time I have ever seen so many warning messages was when I tried to compile my first Pascal program and mistakenly had used {}'s instead of BEGIN/END. The volume of output (from PC) was ludicrous; given the scripts and modules were all tested, well-exercised, thoroughly debugged code.

        First, I tried to # no perlcritic all the failing lines in one script of about 20 lines that had probably taken me 15 or 20 minutes to write, it took nearly an hour to understand what each message was meant to be warning me of -- there were a few warnings that without the benefit of PBP; I simply never did understand. The result was that the script almost doubled in size, and became unreadable because of all the garbage non-comments.

        So then I tried to evolve one of the modules to pass without disabling. I gave up on the script and the first two modules; because they simply could not be made complient and still work. That took almost two hours and the result wasn't like Java. It was worse. it over doubled in size because of all the useful idioms that had to be rewritten into prozaic generic syntac. And it ran substantially more slowly. But worse, with twice as many lines, it almost certainly contained twice as many bugs as a result. It was definitely twice as hard to understand (more lines; more to read and understand, for an experienced Perler), and therefore harder to maintain.

        So, to the idea that I could disable those warnings that I disliked. I did. I simply stopped using it. There's more about that further down...

      2. The novice.

        The novice starts using PC up front; and discovers that every line of code he attempts to copy or adapt from any Perl books he has access to -- from mastering Perl to Perl in a Nutshell to Perl for Dummies and everything in between -- won't pass PC's default settings.

        But how can he configure it? He doesn't have the experience to know which warnings he should heed and which to ignore.

        Beginner's have enough trouble with warnings; if they get around to adding it, as often as not they end up commenting it out. With PC, even if they copy the literature slavishly, they still get whinged at for doing the wrong thing. Talk about discouraging.

      ... If I disable everything; what good is PC doing for me? It isn't But when I use the types of things it warns ne about; I do so with consideration at the time; what point is there to having it remind me?

      For example: I purposely choose to use bareword file handles in top level scripts. I do this on the basis that different things should look different; and a top level script *OWNS* the global namespace so there is no conflict as modules should *never* mess with globals. And in modules -- complying with that rule -- I always use lexical file handles.

      So now I would need two configurations for PC. And then another for another (personal) rule; and another; and another...SO then the game is deciding which of those configurations I should run against this particular script or module. But that is pointless because I already made my decision when I wrote the code.

      And that's the second argument against PC. It does static analysis, after-the-fact. I do my analysis dynamically, as I write the code. Anything it chooses to tell me about, I've already made my decision about. (Or I don't want to hear it in the first place!)

      And finally, it is completely possible to write totally unintelligible, crap, wrong and dangerous code that no amount of PC's static analysis will ever detect. Which means it still comes down to testing to determine whether the code does what it is meant to do or not. And once I've done my testing and concluded it works; I couldn't give two monkey's hoots whether some anal retentive, failed Perler, wannabe Java coder thinks the way I've achieved that is sliced bread or moldy goat's cheese.

      Passing my tests won't guarantee that it is 100% bug free; but if it fails in use, it won't be down to anything that PC would have told me about.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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.

        thinks the way I've achieved that is sliced bread or moldy goat's cheese.

        I think you meant to insert moldy goat turds cause moldy cheese is yum :p

        Perl::Critic's power is not in slavish devotion to its default rules, its in its ability to be configured, its robotic ability to run the same checks again and again, its ability to communicate your style to the rest of your project, and its ability to teach new styles.

        Configuration: Shutting up Perl::Critic with #nocritic is not how you do it. Like any other system that gives you false warnings, you will eventually get frustrated playing whack-a-mole and start ignoring them. There is a .perlcriticrc which has per project and per user configuration. You can turn rules on, turn rules off, change their severity and generally configure them. Here's the .perlcritic from Test-Simple. Perl::Critic has to pick something for its defaults, they're never going to be acceptable to everyone (though some of them are whoppers), accept that and put a little effort into configuring it.

        Repeatability: This leads to the second strength of Perl::Critic, its your robot monkey. Like automated tests, the great strength of Perl::Critic is that it can perform the same mind numbingly complicated task over and over and over again and do it perfectly (or at least equally wrong) every time. While humans might be better than robots at making heuristic decisions, which really good style judgements require, humans are terrible at making repeated rote judgements. This is what Perl::Critic aims to do, the simple (and sometimes not so simple) judgements, across acres of code, again and again. This leaves the humans to do what they're best at. I've been programming Perl for 15 years and Perl::Critic still picks up mistakes. In fact it just found a case where I forgot to turn on strict and warnings, how about that.

        Perl::Critic also acts as the pair over your shoulder saying "can't you do that better?" Is that variable declared with too broad a scope? Shouldn't you use three arg open? Do you really need to turn off strict refs for the whole subroutine? Couldn't you do that with a dynamic method call rather than an eval STRING? Did you forget an explicit return?

        Communication: This leads into the next strength of Perl::Critic, if you put a .perlcriticrc in your project then everyone working on the project gets to use it. Along with a .perltidy, .perlcriticrc clearly communicates and checks the project style without having to read a big out of date wiki page or something. Whether your contributor is a novice who doesn't know what they're doing, or an expert that THINKS they know what they're doing, perlcritic and perltidy make it very easy for them to review their code and follow the standards.

        As important, those standards are written down and must be followed by all. This avoids the common case where the project leader makes it up as they go along, and gets to commit sloppy code when they want to. The perlcritic policy chosen by the project might stink, but at least its a known quantity that everybody has to live with. Once its known, it can be debated and fixed in a useful manner. perlcritic and perltidy have kept me honest.

        Education: Finally, perlcritic teaches you things. Maybe it just constantly complains about a bad or out of date habit you have, or maybe it shows you something totally new. Three arg open is a great example, perlcritic has knocked that habit out of me. For newbies, bareword filehandles would be a very common one (considering the Perl documentation is loaded with them).

        And it doesn't even have to be a human its teaching, it might be a very old code base. The ancient ExtUtils::MakeMaker code is now much better because we put some work into making it pass basic perlcritic. Auditing all that code by eye would have taken stupid amounts of time and I'm sure we'd have been much lazier about it.

        I don't agree with many things Perl::Critic does by default, but its defaults are Perl::Critic's great weakness. Play to your tool's strengths instead. If you're devoting your energy to fighting Perl::Critic's default rules rather than configuring them, perhaps you have an issue with authority.

        If you're arguing that the default choices are inappropriate and that the choices should be updated to reflect current Perl programming practices, I'd say that's generally correct (though there are, as I mentioned, a number of things you should, in general, do unless you are a highly-sophisticated programmer and know exactly what you are doing and what risks you are taking).

        There is, however, a certain amount of handwaving in your argument against static analysis as a technique in itself. You say you "do my analysis dynamically". What does that mean? As far as I can tell, it means that you decide what to do as you write, determining as you write whether or not you will use a given construct.

        For your bareword file handles example, does "I can safely use this bareword filehandle because I know I haven't used it anywhere else, and I'm sure that no module I've used uses this filehandle either because I've read them and made sure" capture the process?

        Because that's still static textual analysis - you just happen to be using your brain and not a program to do it. If "dynamic analysis" means something else to you, it would be interesting to hear more about that.

        As for points 1 and 2, all I can say is: Amen!

        ( Much of the rest I agree with at least to some extent; but nothing to shout praise for nor to quibble over. :)

        - tye        

Re^2: The Most Essential Perl Development Tools Today
by topher (Scribe) on Jan 08, 2013 at 06:38 UTC

    I'm going to have to pretty much entirely disagree with you.

    I get the feeling from your arguments that you have your mind entirely made up to hate Perl::Critic, so I know nothing I say will convince you of it's usefullness. However, I have used it with multiple inexperienced Perl coders at work and found that it significantly improved their code quality. It introduced them to best practices that they weren't familiar with, and provided a sanity check for them against common mistakes.

    They are inexperienced. They don't know common idioms and best practices. And they're never going to learn it without someone (or something) correcting them. Perl::Critic is a great start. Do they follow everything it suggests? No. But they're not complete idiots, incapable of doing research on their own. If something comes up that they aren't sure about, they search online, or ask someone else about it. They learn from it.

    You seem to think that using Perl::Critic prevents people from gaining experience, although I'm unable to see any logic in that assertion. How exactly are people supposed to gain experience by making the same mistakes over and over, never realizing that they're making mistakes?

    Perl::Critic helps immature Perl programmers improve. It helps out of date Perl programmers learn Modern Perl practices. It's an incredibly useful tool, and I personally have benefitted greatly from it's use.

    Oh, yeah; I do run my code through it regularly, too. It makes for a great sanity check to make sure I didn't make silly mistakes.

      Downvoted!

      Here's why: You do not put forward any arguments for either the authority or efficacy of the result of compliance with P::C. Nor do you state an single example or any reasoning for your conclusion that P::C improves beginners code.

      You go one to say that: "But they're not complete idiots, incapable of doing research on their own."; clearly indicating that not everything P::C recommends is sacrosanct. But which ones? How does the beginner know which of the thousands of spurious and pointless whinges that P::C spews at them is worthy of further research?

      And, when they reach different conclusions to you; are you going to accept their "beginner's research" judgement in good faith?

      Or will you simply judge anyone who has a differing opinion to you, not as one who has taken the time and research and thought to have reach the point of having their mind entirely made up; but rather as someone who exhibits "hate" for a piece of software, as you have accused me?

      You simply state: "I like; I use it; therefore it must be good."

      Which is the exact same problem as P::C. It codifies an opinion as having authority on the basis of puerile and simplistic justifications. And without open and transparent debate and the reaching of some kind of consensus; it does not bear that authority.

      Pick (almost) any single one of P::C critiques and open up the discussion here to all comers comments; and I'll bet you'll never reach a consensus; without you give a specific example of the critiqued construct or idiom in situ. And even if you get a consensus for that specific usage, it will be only for that specific usage; and probably a contrived one at that.

      And for every supporting example; an alternative challenging example will be contrivable.

      And that is the crux of my position; P::C does not (and cannot) take context into consideration. It attempts to make black or white that which is inherently gray.

      And they're never going to learn it without someone (or something) correcting them.

      Exactly so. But demeaning the programmer's art and experience by allowing the substitution a dumb pattern matching algorithm, for proper (human) code reviews, is the greatest danger of a piece of software like P::C. It diminishes the knowledge, experience, intuition and dedication of the programmer to that of an electronic cardboard cutout.

      A surgeon friend of mine agrees that software is at least as hard and complex as surgery; and it takes 7 - 10 years before a surgeon is considered qualified.

      If you personally find P::C useful to you, I have no problem with that -- it it your time and cycles you are wasting -- but suggesting that it is a good way to teach new programmers is bordering on criminality as far as I'm concerned.

      I've spent 35+ years acquiring my programming skills; and I'm not about to substitute my experience, intuition and judgement with a dumb text matching script. And I heartily commend anyone who considers programming to be more than a rote-learnt way to earn a crust, to consider carefully the efficacy of same.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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.
      p

        Downvoted!

        Here's why: You do not put forward any arguments for either the authority or efficacy of the result of compliance with P::C. Nor do you state an single example or any reasoning for your conclusion that P::C improves beginners code.

        Wow. You disagree with me, so you downvote me. Thank you for ensuring that I won't get into any future discussions with you.

        However, that isn't quite correct. I specifically said that since we started using Perl::Critic with some of the inexperienced guys I work with, their code quality has improved, and the number of mistakes they have made has decreased. That specific experience is why I believe it helps improves beginners code: I have personally seen it happen.

        You simply state: "I like; I use it; therefore it must be good."

        No, I didn't. I'll thank you for not putting words in my mouth. In fact, I'll help you by directly stating what I mean, in my own words: "I like it. I have personally benefited from it, both through direct use, and from its use by coworkers. For my purposes, it is a good and useful tool."

        Pick (almost) any single one of P::C critiques and open up the discussion here to all comers comments; and I'll bet you'll never reach a consensus; without you give a specific example of the critiqued construct or idiom in situ. And even if you get a consensus for that specific usage, it will be only for that specific usage; and probably a contrived one at that.

        You are correct in that you will probably never get 100% agreement on, well, pretty much anything related to Perl. Especially when it comes to things like best practices. Hell, getting 100% agreement is almost a violation of Perl's TIMTOWTDI culture. But, that doesn't mean that I don't have personal opinions on best practices. And it doesn't mean that a significant number of people in the community don't have opinions on best practices. And it doesn't mean that my coworkers don't have opinions on best practices.

        Can Perl::Critical assist us, at least to some degree, with catching violations of those best practices? Yes. Is Perl::Critic perfect? Absolutely not. Is it useful? To me, absolutely. Do I think it's better to have new users run it, research what it spits out, and learn from it, rather than blindly continue making potential mistakes? Yes.

        I think this comes down to a fundamental difference in viewpoint on learning. You seem to imply that Perl::Critic is always bad, and that the only valid way to learn best practices is through code reviews with a presumably experienced Perl coder. I believe that a code review with an experienced Perler is absolutely better than Perl::Critic, but I also believe Perl::Critic is better than nothing (and many people don't have a Perl guru at their beck and call). Finally, I also believe that Perl::Critic use, especially when supervised by an experienced Perl coder, can be a very beneficial tool for learning.

        I find it to be (one of many) useful tools. You obviously hate it. Nothing in this discussion is going to change either of our opinions, and I'm not interested in arguing with someone who downvotes first, and argues later. I'm out.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2014-12-27 06:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls