http://www.perlmonks.org?node_id=1011684


in reply to Re^4: The Most Essential Perl Development Tools Today
in thread The Most Essential Perl Development Tools Today

perhaps you have an issue with authority.

Ignoring the ad hominem implications; I'll respond seriously.

The only "issue" I have with authority; is that I understand its definition, which for the purposes of this discussion can be defined as:

authority refers to a claim of legitimacy, the justification and right to exercise that power.

Who is qualified to decide that statement modifiers are verbotten? Or that map must use the block form; but also must only contain a single, non $_-modifying statement?

Or that I should have to use some crass artificial construction like:for my $array_index ( map{ $_ *5 +3 } 0 .. int( $#array / 5 ) ) { ...}

Rather than for( my $i = 3; $i < @array; $i += 5 ) { ... }

Because, unless s/he can justify that with a logical reason that goes beyond their personal preference -- and that means way, way beyond the PBP justifictions for those things -- and the only way that could be done is to cite a real, non-contrived example of where those things produce bad code; not just give pause for thought to those new to Perl (or too lazy to get beyond the basics); and that person has greater relevant experience than I; I do not recognise that person as having any "authority".

As my boss -- or, at least notionally, my customer -- you may have the power to impose your edict upon me; but that is not authority.

I've said it once in this thread, but it bears saying again. P::C does not test anything. It will never find a bug that would not be found by proper testing.

The very best it can do (after code has been properly tested) is find potential bugs and potential misunderstandings. But applications are not improved by prematurely fixing potential bugs; and maintenance is not improved by avoiding training. It may be cheapened, but not improved.

And you cannot avoid testing by using P::C -- hopefully that statement doesn't need justifying -- so if you have to test anyway; and P::C cannot find bugs that testing won't; in the end all you have is a poor substitute for proper code reviews and a bean counting exercise.

Or to put it in financial terms; a pure cost exercise with no measurable benefit.

With a thought-through configuration used (once) on a new-to-you code base; P::C can be a useful tool for the individual programmer to find their way around. But as a repetitive pass over on-going development; it is little more than a feel-good statistic and an arse covering exercise. A waste of cycles and power and time.

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.

Replies are listed 'Best First'.
Re^6: The Most Essential Perl Development Tools Today
by tobyink (Canon) on Jan 05, 2013 at 23:29 UTC

    While I mostly agree with this there is one use case for P::C that hasn't been mentioned yet, but I can see the potential benefit.

    Let's assume that I always use the two argument open. But that a few days ago, I made a new year's resolution to embrace three argument open as a matter of personal preference. I could use P::C with a highly stripped down configuration to remind myself not to use two argument open on all my code for the next couple of months until muscle memory takes over.

    So the use case is: reminding yourself about style guidelines that you have decided to follow, yet sometimes forget through laziness or force of habit. After a little while you probably start doing it automatically and can then abandon P::C. Or you don't, and decide to go back to your old way.

    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
[reply]
[d/l]
[select]
Re^6: The Most Essential Perl Development Tools Today
by topher (Scribe) on Jan 08, 2013 at 06:20 UTC

    Did you forget an explicit return? Forget? No. Omit? Quite likely. Live with it. Cos nothing in this world is going to make me give up a 400% speed gain: 

    [0] Perl> sub a(){ 1 }; sub b(){ return 1; };; [0] Perl> cmpthese -1,{
+ a=>q[ a() for 1 .. 1000;], b=>q[b() for 1 .. 1 +000;] };; Rate b a b
+ 4668/s -- -80% a 23195/s 397% --
[download]

    [download]
    Just in case some (Perl) newbie doesn't get that subroutines return the value of their last expression and need a keyword to tell them so. No way José.

    Your benchmark is rather bogus. The performance "hit" from the return statement is negligible. It's the prototype for no arguments with no return statement that gives a seeming big return (I'm guessing the interpreter is optimizing it to nearly a no-op).

    $ perl -E 'use Benchmark qw(timethese cmpthese); sub a() { 1 }; sub b(
+) { return 1 }; cmpthese -1,{ a=>q[ a() for 1 .. 1000;], b=>q[b() for
+ 1 .. 1000;] };'
     Rate    b    a
b  2694/s   -- -88%
a 23209/s 761%   --
$ perl -E 'use Benchmark qw(timethese cmpthese); sub a { 1 }; sub b { 
+return 1 }; cmpthese -1,{ a=>q[ a() for 1 .. 1000;], b=>q[b() for 1 .
+. 1000;] };'
    Rate   b   a
b 2595/s  -- -8%
a 2823/s  9%  --

    [download]

    Is there a performance gain from not using return in this spot? Yes.

    Is it a premature micro-optimization which is unlikely to have anything but a negligible impact the vast majority of real world code? Yes.

    Would I consider this performance gain an invalid reason to skip a return statement on any code that hasn't been profiled and clearly shown to benefit from this micro-optimization? Yes.

[reply]
[d/l]
[select]
      to skip a return statement

      Would I consider the flagrant waste of even 10% of cycles through the addition of a redundant and purposeless extra keyword, an affectation who's time has past. Emphatically so!.

      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.
[reply]
        As mentioned in another comment, I don't have a problem with omitting a return statement when it makes sense. I just don't think that performance is a good reason to do so.
[reply]

      Is it a premature micro-optimization which is unlikely to have anything but a negligible impact the vast majority of real world code? Yes.

      No, its called style :)

      map, grep, sort, s{}{...}e don't allow you to use return, they force you to use implicit return

      explicit return isn't required in do/eval/sub

      return tells you about this

      so unless you're coding something recursive, something that requires short circuiting, most perlish perl programmers omit the explicit return, and use the implicit return

      If explicit return costs more (I'll take BrowserUk's word that it does), its a problem with the implementation, something for p5p to fix, same as they did for map in void context

[reply]

        Please note, I'm not saying that you should always use a return statement. I'm not even saying that you should usually use an explicit return statement.

        I have absolutely no problem with omitting it in any and all cases where it makes sense. I just don't think that the negligible performance difference is a good justification for not using it. Coding style, clarity, and lack of need are all good reasons to omit it; performance isn't.

[reply]

In Section Seekers of Perl Wisdom