Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^7: Modern Perl and the Future of Perl

by shmem (Chancellor)
on Dec 21, 2007 at 19:40 UTC ( #658511=note: print w/replies, xml ) Need Help??


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

It's not clear that those constructs are always bugs, but they all deserve investigation. P::C can detect those in a large codebase, along with other constructs which we now know to be risky.

These risky constructs deserve a prominent place in e.g. perltrap (which up to this day is full of obsolete perl4-perl5 traps. I'll try to write a patch.) That's all that is necessary. That documentation should show up in the perl docs, not as a Perl::Critic policy complaint after the fact.

If somebody uses risky constructs in production code, that programmer is a risk to your business. And risky constructs aren't just the ones you mention, but every half-known construct.

Do you still occasionally use pseudo-static lexical variables when you shouldn't? Don't code drunk, then. Do you need Perl::Critic to detect them in your code? I bet all you get is false positives.

Now I don't know what's happened to you and BrowserUK that your hands jerk off the keyboard in shock whenever someone suggests that your team should consider agreeing on the use of a tool that can help you identify things in code that you need to think about, but that's fine.

It's because it is the wrong tool which doesn't solve the problems it promises to solve!

I have much the same reaction whenever I hear of people that have a "personal firewall" on their box. I'm always glad if I can direct them to the Personal Firewall FAQ. If you need Perl::Critic, your problem is somewhere else. See my other post.

--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^7: Modern Perl and the Future of Perl

Replies are listed 'Best First'.
Re^8: Modern Perl and the Future of Perl
by chromatic (Archbishop) on Dec 22, 2007 at 02:12 UTC
    Don't code drunk, then.

    Yeah, and if I can go 10 seconds without writing a bug, I can go 30 seconds without writing a bug. If I can go 30 seconds without writing a bug, surely I can go 2 minutes without writing a bug. If I can go 2 minutes without writing a bug, I can go 20 minutes without writing a bug, and so on, and so forth, ad infinitum.

    Likewise a team that always did the right thing every time without having to think about it would never need a software development process. Let me know if you ever hear of such a team.

    I can often go 10 seconds without writing a bug. I still write tests though.

    I sometimes realize a few months into a project that I've been making a mistake for a while, and I need to find and fix it every time it occurs in my code. Sure, there's grep and App::Ack, but they're linear textual searches (regexes notwithstanding), and there's a big difference between that and a search over the canonical tree structure of Perl documents. P::C gives me a way to do that, and to stop those problems from coming up again in the future.

    It's nice that you have the luxury of never making mistakes. If you can teach people everywhere how to stop being not perfect while coding, I'll stop recommending the use of tools which, when used intelligently, can help them code better until they reach your level of transcendent perfection.

      Yeah, and if I can go 10 seconds without writing a bug, I can go 30 seconds without writing a bug. If I can go 30 seconds without writing a bug, surely I can go 2 minutes without writing a bug. If I can go 2 minutes without writing a bug, I can go 20 minutes without writing a bug, and so on, and so forth, ad infinitum.

      Likewise a team that always did the right thing every time without having to think about it would never need a software development process. Let me know if you ever hear of such a team.

      These statements don't add anything to the discussion; you try to make me look like a fool, which is a rhetoric trick I deeply detest. Thank you.
      I can often go 10 seconds without writing a bug. I still write tests though.

      Yeah, me 2. And then you run Perl::Critic over your code, do you?

      I write bugs, and often nasty bugs, and I do that despite knowing Perl Best Practices, and those bugs aren't product of best practice violation. It often takes me a ridiculously long time to spot them, because I am blind to them. So is P::C.

      But then, I am quick in spotting bugs in code others wrote. My posts here back that.

      I go over that code, see a different mindset, try to get what they thought, and how they think, how they lay out their thoughts and how they cast them into code. It is like exploring an unknown land, or deciphering an unknown dialect. The mere difference to my own thoughts incite my curiosity and my concentration. I see patterns, go over the rough edges, compare idioms I find to my own. As I re-create the logic of the programm I follow, suddenly I see what's wrong. There.

      How would that be if everyone would code as I do? Would that also be an exciting journey into somebody else's thoughts? I guess not.

      Would I have developed the same ability of spotting oddities if all perl code I have seen had been uniform? I guess not.

      I sometimes realize a few months into a project that I've been making a mistake for a while, and I need to find and fix it every time it occurs in my code. Sure, there's grep and App::Ack, but they're linear textual searches (regexes notwithstanding), and there's a big difference between that and a search over the canonical tree structure of Perl documents. P::C gives me a way to do that, and to stop those problems from coming up again in the future.

      So you write a rule for Perl::Critic to detect all occurrences, and succeed with that? Good. That sounds like just occasional use of P::C, and a good one, which has nothing to do with setting up a set of rules and use P::C to report violations to coding standards.

      And, you spotted that mistake without P::C, did you? And fixed the rules afterwards?

      It's nice that you have the luxury of never making mistakes. If you can teach people everywhere how to stop being not perfect while coding, I'll stop recommending the use of tools which, when used intelligently, can help them code better until they reach your level of transcendent perfection.

      Again you are trying to make me look like a fool. You don't need that; leave that to Cop.

      Needless to say that I'm far from perfect and will never be. There's no way to teach people how to stop not being perfect, but there are ways to make them good coworkers, to make them a good team, to make them good code readers. P::C is not useful to get accustomed to a wide variety of idioms, patterns and ways of expression, because it reduces the set.

      And that richness in patterns, ideas, idioms is what makes a good programmer. Knowing how the language works you have at hand makes a good programmer. Being able to read someone else's code makes a good programmer. Writing your code in a way that others grok it because you just know you want to do it that way makes a good programmer.

      P::C isn't useful to achieve any of those goals. I'm willing to discuss that further.

      But even a tool conceived for a not-so-well-thought-out purpose has its good uses.

      I have a tank. Sometimes I use it to drag cars out of the mud. Everyone should have a tank and use it.

      If Perl::Critic would not be so tightly coupled to Perl Best Practices; if there were no emphasis on it being a tool to verify good coding standards; if it would just be taken as a tool to detect code patterns, as your described usage suggests - then it would be a great tool (it actually is in that sense). But its promoted usage is dangerous and bad practice.

      --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}
        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://658511]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (2)
As of 2018-04-25 22:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?