Perl Foundation elects new chairman, president and vice-president

The Perl Foundation announced today that they new positions have been elected in the Board of Directors. Bill Odom, previously President, becomes Chairman; Richard Dice becomes President; and Jim Brandt becomes Vice President. Kevin Lenzo who has for so long served the Foundation leaves his Chairman position and becomes Director Emeritus.

Perl::Critic: an interview with Chris Dolan

Chris Dolan recently received a Perl Foundation Grant to write 20 new policy modules for Perl::Critic. I managed to catch up with Chris by email and ask him a bunch of questions about his work on Perl::Critic, the TPF grant, and more.

Kirrily: So, how did you first get involved in Perl::Critic?

Chris: Funny, I had to look back at my email to remember this. You’d think I could remember two years ago…

I read Damian Conway’s Perl Best Practices (aka PBP) in summer 2005 and thought, “Finally! The solution to the ‘Perl is not readable’ myth!” I tried applying all of the ideas manually in a new module I was just about to release to CPAN (Net::IP::Match::Regexp). I found the process rewarding, but a little tedious and error-prone.

After working with the PBP recommendations manually, I thought about writing some code to judge some of the recommendations automatically, but happily I decided to check CPAN first. I found Perl::Metric::Basic and posted some RT reports. Then I found Perl::Critic, which had just been renamed from Perl::Review. I found the code much more approachable that Perl::Metric and soon filed a few RT reports and a cpanratings review. Jeff Thalhammer, the P::C creator and leader, emailed me back personally thanking me for the feedback. After that, we had about a dozen back-and-forths where Jeff sent me pre-release tarballs of Perl::Critic and Test::Perl::Critic to test before sending them to CPAN. Then, I wrote my first from-scratch policy (Modules::RequireEndWithOne) about a month later, and I was hooked.

Kirrily: What prompted you to apply for a TPF grant? How did you convince them to give you money? How did you find the grant process?

Chris: I hope nobody criticizes me for admitting this, but my reason for applying for the grant was self-motivation. Our second child was born Jan 1, 2007 and the company where I worked was struggling, so it was a hard time to find energy for my open source efforts. I usually work best under pressure, so I decided the publicity of a TPF grant would force me to get something done (and the money will be a nice bonus too).

I wrote a ton of grant proposals in my former life as an astronomer and, of course, tons of business proposals as a web/programming consultant, so I found the TPF grant process pretty easy. The positive impact of Perl::Critic is obvious on the community of people who care about good Perl code, so the justification part was straightforward. The harder part was deciding what part of P::C to
propose to build.

Kirrily: Is there a theme or themes to the 20 modules you’re doing?

Chris: Yep. We keep an extensive TODO.pod file in the P::C svn repository. One portion of that file is devoted to PBP recommendations that seemed feasible to implement in code. I had created that list over a year earlier by paging through the PBP book and brainstorming implementations for each recommendation. Needless to say, some of the PBP recommendations will never make it into P::C — for example “Never assume warning-free compilation implies correctness” (page 432).

It turned out there were an even 20 PBP-based ideas in the TODO list (vs. about 40 non-PBP ideas). Twenty seemed like a nice round number and a challenging-but-doable quantity. At that time, I was primary
author of 27 of the 93 finished policies, so I had a pretty good idea of what was involved.

Kirrily: Why should people use Perl Critic? Why shouldn’t they?

Chris: In my opinion, it’s good for two things:

1) Finding bugs (real bugs and potential bugs)

2) Making your code more approachable

Both are especially important for open source code that might be used by thousands of other programmers. Why write bad open source code?

One reason not to use Perl::Critic is to put a badge of honor on your code. Achieving P::C compliance is a good thing to announce to the world because it tells users that you care about the quality and consistency of your code. But P::C doesn’t help make your code better directly. It just tells you that your code isn’t broken in one of about 100+ known ways. And some of those 100+ contradict each other! Compare that to the innumerable ways to write bad code. So, you’ve got to start with good code and use P::C as a tool to make it a little better.

One piece of advice I like to share is that you should not be afraid to turn off P::C policies that don’t work for your code. I think Damian gave similar advice in PBP. In the P::C code itself, we have 98 instances of ## no critic(...) which turns off certain policies. Even Perl::Critic is not 100% Perl::Critic compliant! But
98 out of 27,000 lines of code isn’t bad.

Another controversial topic is whether .t files should be P::C compliant. Personally, I don’t bother. Writing test code needs to be fast and easy or it falls by the wayside.

Kirrily: Do you know of any really interesting uses of P::C out there? Famous companies using it?

Chris: Good question. We should ask Jeff Thalhammer about that — as P::C founder, he has a closer connection to our user community. There was brief talk about creating a for-profit consulting entity to help big companies write better code using P::C, but I don’t think anything came of that (I was too busy to participate).

What I find interesting is the people/groups/companies who have privately implemented their own policies for P::C. Parrot, for example, had a few custom policies the last time I looked. Another example is MathWorks, who funded the Perl::Critic developers to write some specific policies they desired. Now that’s a business model any open source developer craves!

Kirrily: What next after you’ve implemented these P::C modules?

Hmm, I have no real plans. More policies, I guess. I’d love to get more people writing them. They aren’t too hard to create and without them P::C is worthless. If anyone wants to get involved, I’d be happy to be a mentor. Giving fish vs. teaching fishing, y’know.

In my day job, I do a lot of Java coding (and often enjoy it). We use a commercial package called CodePro by Instantiations which is conceptually similar to Perl::Critic but is much more polished. They have over 900 policies to choose from, many of them specifically designed to squelch anti-patterns in the big APIs like Spring, Hibernate, Struts, etc. Jealously, I’ve often thought that they have an easier job than we do because Java is so much easier to parse than Perl, and the code smells seem to fall in more easily identifiable patterns.

When Perl 6 becomes popular, I’d like to see Perl::Critic be implemented against it. Perl 6 will have a grammar that is much more amenable to grepping. Behind the scenes, I’d like to see the Perl 6 version of P::C work against de-sugared syntax or perhaps even the abstract syntax tree to simplify the policy writing. Unless a huge amount of work goes into improving PPI, that’s not going to happen for Perl 5. At one point, we talked about writing P::C policies using an XPath-like notation, but nobody ever championed that goal.
I discovered that FindBugs (another Java code analysis tool) took that approach successfully. Maybe P::C can benefit from the Parrot tree grammar engine (TGE). Or the optimizer. After all, the syntax
pattern matching that P::C has to do is not that different from the opcode pattern matching that an optimizer performs.

Overall, what I’d really love is for Perl 6 to avoid the “write-only language” moniker that got slapped on Perl 4 and Perl 5. If P::C can help with that, then it has succeeded.

Thanks, Chris!

Find out more about Perl::Critic at PerlCritic.com or listen to this PerlCast interview with Jeff Thalhammer, creator of Perl::Critic.

Countdown to Pittsburgh Perl Workshop: Schedule released

One month to go, and the schedule for the Pittsburgh Perl Workshop has been released, and it looks like a great lineup.

Wish I could be there! But I’ll be there in spirit, at least; Michael Schwern will be presenting the results of the Perl Survey at PPW.

Perl’s alive and kicking in the job market

langjobs.png

renodino writes in his use.perl.org journal that he’s sick of hearing FUD about how Perl is dead. So, he built a quick graph of job ads on Dice.com:

His graph shows Perl jobs as the blue bar, with the dark blue bar next to it being those jobs which specify Perl as well as any other dynamic language. It’s pretty obvious that if you’re looking for a job programming in a dynamic language, Perl is the way to go.

renodino writes that he’s intending to update the graph regularly, so it will be interesting to see whether Perl can maintain its huge lead over time.

mod_perl 2 User’s Guide published: An interview with co-author Jim Brandt


mod_perl2 User’s Guide (modperl2book.org) by Stas Bekman and Jim Brandt has
just been published by Onyx Neon, and Amazon says it’s shipping.
I can’t think of the last time I’ve been as excited to see a Perl
book get published. Besides brian d foy‘s
Mastering Perl, there hasn’t been a significant Perl book
in quite a while. Perlbuzz is going to work with Onyx Neon to have a book
giveaway, so watch this space in the next few days.

Jim Brandt took some time to talk with me about the book, why you
need to switch to mod_perl 2, and why it took so long to get
the book to market.

Continue reading “mod_perl 2 User’s Guide published: An interview with co-author Jim Brandt”

ctags 5.7 improves Perl support

Exuberant ctags, the standard tags utility on most systems today, has released version 5.7 for download with the following improvements to its Perl support (among many other improvements):

  • Added support for ‘package’ keyword
  • Added support for multi-line subroutine, package, and constant definitions
  • Added support for optional subroutine declarations
  • Added support for formats
  • Ignore comments mixed into definitions and declarations
  • Fixed detecting labels with whitespace after label name
  • Fixed misidentification of fully qualified function calls as labels

If you’ve never used tags or ctags, start today. Your life will never be the same after.

For example, if you run ctags on a tree of source code, and then run vim -t some_function from the shell, vim will open the file where some_function lives and leave your cursor there. Alternatively, if you’re editing a file with vim and you position your cursor over the word some_function and press Ctrl-], vim will jump to the function. Other editors have similar bindings.

Your editor doesn’t know Perl, but it relies on ctags generating a tags file, which is in a standard file. Of course, ctags isn’t perl itself, so isn’t as exact. These improvements in v5.7 will make your tag files more accurate.

If you’ve got a Perl module, it’s easy to add a makefile target for tags. See any of my major modules (WWW::Mechanize, ack, etc) and steal from the Makefile.PL, or just add the following to your Makefile.PL:

sub MY::postamble {
my $postamble = <<'MAKE_FRAG';
.PHONY: tags
tags:
ctags -f tags --recurse --totals 
--exclude=blib 
--exclude=.svn 
--exclude='*~' 
--languages=Perl --langmap=Perl:+.t 
MAKE_FRAG
}

(With ctags 5.7 it turns out, that --exclude=.svn is no longer necessary, as ctags automatically knows to ignore it now.)