Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

My CPAN Resolutions

by Tommy (Chaplain)
on Jan 01, 2013 at 02:29 UTC ( #1011110=perlmeditation: print w/replies, xml ) Need Help??

Ready the flame retardant! I know there are monks who don't like Dist::Zilla...or my modules... or me... But in the past such criticisms have only served to make me a better Perl hacker than before I was criticized, and (more importantly) guided me to improve my code. I fear the day when people stop offering me negative feedback (because that will probably be when I'm dead HAR HAR). So:

A couple of days ago I moved File::Util to git+Dist::Zilla, and added Perl::Critic into the mix. This was on my list of resolutions, but not just for the new year. It's more because I think I owe it to the community to keep offering better things and generally never cease trying to improve.

Euphoric Observations and Kvetches:

  1. git is so frikkin easy; you're over-thinking it-- just type "git" and you'll "get" it (how anyone manages to write a whole book on something so simple is a real puzzler)
  2. Dist::Zilla was a pain in the *censored* to get working, but it really was worth it, especially with the many plugins that make being a CPAN author waaaay more easy and fun
  3. Perl::Critic is mean (wah ;_;). I like to eval 'expressions'; Perl::Critic does not.
  4. Perl::Critic cites the Perl Best Practices book for everything it complains about. The book is not free, and the references to page numbers are USELESS when you decide to shell out the money, but buy the more budget-conscious kindle version instead. Kindle doesn't have real page numbers! Hello McFly!
  5. Dist::Zilla fosters and facilitates "kwalitee" (as in CPANTS) by generating/maintaining certain "meta" files that you might forget to add or update before packing up your dist. (version control and the MANIFEST admittedly help with the "add" part, but Dist::Zilla still has your back in this regard, should you mistakenly un-add something that should be there)
  6. My CPAN modules will from now on have much better kwalitee, pass Perl::Critic tests, include git repo info, build more easily on platforms that don't have a "make" utility, add a Module::Signature to all builds, and other lofty devel snobbery that I haven't yet added to the mental list
  7. The next Perl Mongers meeting will be more fun now that I'll know what I'm talking about as I cover the scheduled topic (collaborative development with git) :-D I'll also be supplementing the curriculum by showing merlyn's presentation video on git which he shared very recently on google+!

That is all.


And with the new year, these resolutions begin to unfold. Over at a new github repo, items are getting checked off the TODO file while I pour another glass of non-alcoholic sparkling white grape Martinelli's

$ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'

Replies are listed 'Best First'.
Re: My CPAN Resolutions (perlcritic)
by toolic (Bishop) on Jan 01, 2013 at 15:04 UTC
    Perl::Critic cites the Perl Best Practices book for everything it complains about. The book is not free, and the references to page numbers are USELESS
    I own the PBP book, but I never use it in conjuction with perlcritic because perlcritic can be configured to access the POD for a given policy. The POD usually explains each policy well enough so that I don't have to go running to the book. See also: Sort and summarize perlcritic output

      ...Which is what I've done, however I've found that the POD is most lacking, especially in the weak justification that to eval 'expressions' is bad because the 'expressions' are recompiled at each invocation and generate no compile-time warnings. Well, gee. I already knew that, and maybe (just maybe) I actually want that behavior for a reason. Is that so crazy? Does that make me evil?

      But that's not my biggest gripe. My gripe is that the POD explanation itself really ... left much to be desired, particularly for this error. Sureley there's something deeper; surely there's some better explanation about why it's bad to eval 'expressions' beyond the two that are provided in the POD. If those are the only reasons not to eval 'expressions', then I don't think it's a bad thing to do when you specificall want the behavior it provides in the first place. Being able to do so is arguably one of the most powerful uses for perl: it can run itself!

      And no, I haven't gone hunting for it in the PBP book (yet) because, again, I have no real page number to reference. I'll see what I can search out later on. If it turns out there's a greater justification to be found, I'll submit a patch to the POD. Otherwise I'll continue to be grateful that I can eval 'expressions' with Perl, because I've found several times that this (bad?) practice has helped me create some really awesome things through the years. Very fast template parsers with support for embedded perl expressions are one thing that comes to mind.

      $ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'

        Stringy eval has its uses. Moose and Moo use it extensively for creating fast inlined accessors and constructors. Template-Toolkit uses it to create templates.

        However it can also enable all sorts of ugly practices. For example, poor man's symbolic references...

        use strict; my $red = '#ff0000'; my $green = '#00ff00'; my $blue = '#0000ff'; my $colour = 'green'; my $hex = eval "\$$colour"; # symbolic reference print "$hex\n";

        When many newcomers turn to stringy eval, it's often because they're unaware of a better solution to their problem.

        This is my problem with Perl::Critic. It takes a generally good guideline (stringy eval is often a bad idea; investigate other options first) and turns it into a concrete rule.

        Yes, of course there's no critic comments but I don't really want to litter those around my code like rat droppings. (no strict and no warnings are already enough of an eyesore.)

        perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

        I can appreciate your frustration when using Perl::Critic without a copy of PBP. Long ago, I asked O'Reilly if I could have permission to quote entire sections of their book in Perl::Critic's POD. They denied my request.

        So we paraphrased PBP in the Perl::Critic documentation. If you see gaps or inaccuracies, feel free to file a bug ( submit a patch ( or request a commit bit (

        Soon after Perl::Critic was released, some folks wanted pages numbers for the French or German translations of the book. Others wanted links to pages on instead of dead-tree page numbers. And now that we have all sorts of e-books, it is even harder to come up with a truly universal form of citation (which sounds like an interesting project in itself).

        A stringy eval() is perfectly correct in some situations, usually having to do with dynamically generated bits of code. But in most other situations, a block eval is a better option.

        All software is just the sum of a long series of decisions. Perl::Critic merely provides you with reasonable defaults for some of those decisions. But all those defaults will be wrong at some point. IMHO, mastering the language means understanding when and why they are wrong.

        Jeffrey Thalhammer
        Imaginative Software Systems

Re: My CPAN Resolutions
by tobyink (Canon) on Jan 01, 2013 at 12:50 UTC

    "git is so frikkin easy"

    Indeed; it's number 5 on my list of the easiest version control systems I've ever used *.

    * though I have only used a total of five different version control systems.

    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

        Just read that thread. I must admit I'm phased. Never imagined... just, wow. That's so much more work than:

        $ git init
        $ git add foo
        $ git commit -m 'just a note'

        It seems that if being extremely lazy was the point, the means didn't justify, much less even come to that end. The humor isn't lost on me though. The documentation is awesome.


      What do you use for revision control, tobyink?

      Just curious.

      $ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'

        These days, Mercurial almost exclusively. Thanks to the wonderful hg-git plugin I can even use it to work on git repositories (and I can mirror my Mercurial repositories on github).

        Mercurial has pretty much all the features of git, but a command-line interface that seems to have been designed by... well... that seems to have been designed, rather than just emerged from chaos like Greek primordial deities.

        perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
Re: My CPAN Resolutions
by sundialsvc4 (Abbot) on Jan 03, 2013 at 18:13 UTC

    Perl::Critic is best for finding rubbish, especially lots of rubbish in a large application, so that you can show your boss or client that “somebody else also says that” we should stop trying to patch this thing and knuckle down and make it better.

      But it can also easily pass a critical threshold of critiques where the boss looks at the report and decides it would just be too much work to fix it.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://1011110]
Approved by davido
Front-paged by Arunbear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2021-12-04 23:13 GMT
Find Nodes?
    Voting Booth?
    R or B?

    Results (30 votes). Check out past polls.