Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: Writing a better Modern::Perl

by JavaFan (Canon)
on Oct 07, 2010 at 16:06 UTC ( #864027=note: print w/ replies, xml ) Need Help??


in reply to Writing a better Modern::Perl

tell me what you think.
Well, I don't think much of it.

First of all, half of the modules it loads, aren't my cup of tea.

But, more importantly, I don't like all those modules that load pragmas for you. I rather much have code where I can just look at the beginning of the file and see that strict, warnings, autodie, and some other pragmas loaded. Do not expect from the people coming after you to memorize a matrix of "modern" pragmas, and what the enable for you.

I do appreciate the effort of avoiding to type 'use strict; use warnings;', etc. But then, for me, "use nextgen;" will be 12 or 13 characters too long. I can have my cake (less typing) and eat it (see the loaded pragmas in the code) with 1 or 0 keystrokes. A single keystroke in my editor loads the template - and if I start off with an empty .pm file, I don't even have to give the single keystroke.

But even if I work on a system where I don't have my editor macros available, I still rather "use 5.010; use strict; use warnings;" than "use nextgen;" (or any other pragma with a similar effect). The two seconds extra it takes to type are earned a hundred fold for each developer after me who has to look up what the hell 'use nextgen' enables.


Comment on Re: Writing a better Modern::Perl
Re^2: Writing a better Modern::Perl
by EvanCarroll (Chaplain) on Oct 07, 2010 at 16:27 UTC

    Right, well by extension you could not `use warnings` - because it essentially does the same by enabling :all, and instead you can use each different type of warning explicitly. You could do the same thing with strict too! Even CORE has to make some defaults: $[ defaults to 0.

    Other than the extremely weak argument you present, the point I'd like to make is that there is a level of reasonableness to getting better defaults. That comes at the cost of "defaults" - choices being made by someone else that *might* not apply to you, but *may* very well be so crafted as to benefit you in every application.



    Evan Carroll
    The most respected person in the whole perl community.
    www.evancarroll.com
      Other than the extremely weak argument you present

      I don't think JavaFan's argument is weak, and you didn't do anything serious to prove your point.

      Also if you don't respect the opinions of those that answer, why ask for opinions in the first place?

      Perl 6 - links to (nearly) everything that is Perl 6.
        It isn't an argument against nextgen, it is an argument against defaults. Why aren't they your cup of tea? would be the question that would permit me to make nextgen better, unfortunately I didn't ask that. Instead, I brought to light the weak merits of arguing against defaults, and against a method that tried to better them.

        And, not respecting one argument does not mean that I do not respect the opinions of others. I respect that he won't use my module because he prefers to replicate boiler plate code through editor macros (for some value of respect), that doesn't mean that the source argument against implicitly doing what you want is a good one, especially for the perl community.



        Evan Carroll
        The most respected person in the whole perl community.
        www.evancarroll.com
      I have nothing against defaults.

      However, if you would be happy with the defaults, you wouldn't toss out one module, and write your own with a different set of defaults.

      I know what "defaults" I get when using 'use warnings', or 'use strict'. I also know they are very unlikely to change, and, if they do, it will require a major Perl release. The defaults for 'use strict' haven't changed since 5.000.

      But with Modern::Perl, nextgen, and other modules enabling lexical pragmas outside of their lexical scope, they aren't defaults. The are choices, choices made by the authors. And regardless whether one agrees with the authors choices, for each module you encounter in code you inherit/maintain, you'll have to find out what it does. That takes an effort.

      Writing good Perl code isn't golfed code. Mentioning the pragmas you're going to use in your program only takes a few seconds of typing. IMO, the benefits of mentioning the pragmas your using far outweight the cost of typing a few lines. It's just like comments. I spend quite a few keystrokes on comments. Sometimes, the comments even look like "boilerplate". Guess what, I don't hide that in a module either.

      EvanCarroll: "Hey, can you give me a ride to the store?"
      Friend: "Sure, let's go."
      EvanCarroll: "Dude, your car sucks."

      Asking someone for their opinion, then arguing against it, teaches people that they should not bother responding to your requests.

      xoxo,
      Andy

Re^2: Writing a better Modern::Perl
by ikegami (Pope) on Oct 08, 2010 at 15:48 UTC

    I still rather "use 5.010; use strict; use warnings;"

    One less now

    $ perl -e'use 5.012; print $x' Global symbol "$x" requires explicit package name at -e line 1. Execution of -e aborted due to compilation errors.
      I will still write 'use strict;' even if I do a 'use 5.012'. It's a little effort, and I'm not going to assume everyone will know that at some point in time use 5.xxx implied use strict, and that they know at which point in time that was.

      Besides, writing "use 5.012;" without a "use strict;" runs the risk someone removes the "use 5.012;" (not unreasonable if there's nothing in the code that actually needs 5.012...), and then have it be without strict.

      I never liked the idea that "use 5.XXX" implies subtle changed behaviour other than "without the mentioned version, it's unlikely to compile". I prefer "use 5.XXX" to mean one of "if you try to compile this with 5.YYY, where YYY < XXX, you'll fail" or "this code will trigger a bug in 5.YYY, which was fixed in 5.XXX". The implicite turning on of strict isn't such a change. Now it mean "if you try to run this with 5.YYY, I'm going to keep quiet if you screw up". Not what I expect of a helpful language.

      I will only slap a "use 5.012;" label on my code if there's actually anything in my code that won't run on 5.010. So far, I've written next to no code that needs 5.012. I'm not going to artificially restrict my code to a certain version just so I don't have to type a few keystrokes (which I don't have to type in the first place - an editor macro does that for me).

        I will only slap a "use 5.012;" label on my code if there's actually anything in my code that won't run on 5.010.

        Me too.

        I will still write 'use strict;' even if I do a 'use 5.012'

        Me too. I've been requiring a Perl version in Makefile if necessary, and I use features to grab the features I use in the scripts and modules.

        or "this code will trigger a bug in 5.YYY, which was fixed in 5.XXX".

        There wouldn't be a need for a pragma in that scenario. features is used for backwards incompatible changes, not pure bug fixes.

        Now it mean "if you try to run this with 5.YYY, I'm going to keep quiet if you screw up". Not what I expect of a helpful language.

        I don't know what you mean. What errors does use 5.xxx; silence?

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2014-12-26 05:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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





    Results (165 votes), past polls