Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^8: Modern Perl and the Future of Perl

by chromatic (Archbishop)
on Dec 22, 2007 at 02:12 UTC ( #658595=note: print w/replies, xml ) Need Help??


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

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.

Replies are listed 'Best First'.
Re^9: Modern Perl and the Future of Perl
by shmem (Chancellor) on Dec 22, 2007 at 11:31 UTC
    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.

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (8)
As of 2018-06-20 15:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?



    Results (116 votes). Check out past polls.

    Notices?