Perl::Critic for the Camel
Tom C. meditated in Perl Monks that he wants Perl::Critic policies to go with the recommendations from Programming Perl, 4th Edition, Chapter 21.
I started it by creating the perl-critic-policy-camel GitHub repo, which is now a bare distribution structure. Now it can accept pull requests. :)
The next step is probably to make a concise list of the recommendations from Chapter 21, and identify which are covered by existing policies.
I'd love to have this as a "camel" theme, like the "cert" theme I wrote about a long time ago.
I'm the author of Mastering Perl, and the co-author of Learning Perl (6th Edition), Intermediate Perl, Programming Perl (4th Edition) and Effective Perl Programming (2nd Edition).
What's wrong with just updating PBP?
Perl Best Practices is a different book by a different author with different recommendations.
Besides that, "just updating" seems like a much more difficult task than you make it out to be. There's nothing wrong with the idea of updating that book, but it's probably not worth the work.
There are some interesting comments in the Perlmonks meditation about the value of updating PBP.
Yes, it is a different book, by a different author, with different recommendations and that's bad.
It's also very old.
It makes it very difficult to impose a baseline set of practices on a project team.
I can't see anything in the meditation you tagged about updating PBP, but this seems to come up every couple of years and we never move forward.
Does anybody know what the sticking point is? How many of the differences are just because the book is old? You wouldn't expect a 2005 book to have much about Unicode in it. Damian Conway may have changed his mind on some things in the last 8 years.
Does Damian Conway refuse to update it or allow it to be updated? Do O'Reilly refuse to allow it to be updated? Is the problem that the community can't put together a little team of "name" authors to give an update gravitas? Is the problem money?
Is there a feeling that the new Camel book is the new PBP? (I confess I haven't read those sections in any detail, I always refer to PBP.)
I suspect "update PBP" was meant to refer to the PBP critic rules, not the book itself.
It doesn't make sense to shove recommendations from "Programming Perl, 4th edition" into the rule set from PBP, for all the reasons described above (different era, different author, different recommendations). Keep them separate, and let the user decide which he wants to apply to his development practices.
Before I get carried away, I like to think of a world where people can choose whatever set of policies make sense for them. Some may choose a straight PBP set, a Camel set, the CERT set, or take some from those sets to create their own. I think it's better to provide alternatives and let the people at the end decide.
But, having said that, don't worship at the Altar of Conway: Despite his accent, charm, movie star good looks, and amazing upper body strength, Damian qualifies what he means by "best".
You might like to re-read Damian's first chapter, or my interview with him in The Perl Review. You shouldn't need a book to tell you what your policies should be. Your experience in your job and in that situation should be your main guidance. Damian just provided some advice and Jeff provided the Perl::Critic framework that was presciently expandable.
I've seen PBP be much more harmful than helpful, losing companies lots of money for me to figure out why their application broke after a PBP zealot added /xsm to every regex.
As for the book update, it doesn't make sense for anyone to spend the huge amounts of time for the money they'll make from it. At every next skill level, a publisher expects to sell only 10% of the lower level. The Alpaca has 1/10th the sales of the Llama. Mastering Perl will have 1/100th the sales. If I weren't already invested in several other Perl titles which subsidize the advance book work, I wouldn't do them.
Damian, like almost everyone else, has to put food on the table. That book never made that much money. The problem is that not enough people will buy his book. O'Reilly are very good about releasing books to authors if they decide against an update. Beyond that, I can't speak for Damian.
The Camel is not the new PBP. It's a different book with different authors who have different preferences and different constraints. Despite the "best practices" in the title of Damian's book, most of that book wasn't about superlative practices. There's no such thing as a best practice outside of any context, and that's the problem with that sort of thinking. It's the wrong place to start. Not only that, best practices are something borne out of long histories of industry practice. You're just not going to get that with anything in Perl. Most things we're doing now will be bad practice in five years.
Randal Schwartz had his own "Perl Second Best Practices" talk, where he counters Damian's preferences with his. As I recall, Dave Rolsky had compiled a list of rebuttals and alternatives to Damian's suggestions.
Hey, I still have that. It's basically my full "Perl Best Practices" talk, but I have annotations on a few dozen of the pages about how I'd do it instead.
brian,
I enjoyed your book on Effective Programming, I even persuaded a couple of local libraries to stock it. I've got a copy of the latest Camel book here, but I've only dipped into it. Surprisingly, the bit I've read is the bit where you laud the format command to the skies. I suspect that was cut and pasted from the previous edition without proof-reading.
I've never achieved any particular pre-eminence, but I can be reasonably confident that I've worked on more development projects than you. It's one of the few certainties that come from getting old.
Much of what you say there is naive and patronising. I can live with being patronised, but you are patronising the other readers as well.
Very few people in any field take "Best Practices" to mean the one and only true way. They mean "Good Practices" or "Recommended Practices". Even in fields where life and death is at stake, people use the "Best Practices" as a starting point and develop project practices. The difference is that you can end up dead or in prison if you deviate without the appropriate authority.
I did not say, or even imply, that I wanted a single set of compulsory rules.
I said that Perl needed a set of rules about which there was reasonable authoratative consensus and that people could use as a baseline. It does.
You don't want to start developing your project standards from a blank sheet of paper every time. Nor, when you are on a new project, do you want to say "Do this because I am wise". You'll spend ages justifying yourself. It's more likely that you'll want to say "Do this because I've done it before, it's recognised as good practice, and all these people agree with me."
Sometimes you'll want to deviate from the standards, sometimes you won't give a damn about standards.
I did not say, or even imply, that I wanted anybody to do a lot of work for free. I do little bits and pieces for the Perl community for free, but I have no intention of doing a lot. Even with the little bits I do, there is a sub-agenda of networking, job protection, paying back favours, etc. Most people are like that.
It sounds like we need a corporate sponsor. Most discussions of this ilk end with that conclusion.
Regards
Duncan
No, I really do like formats. For things I've done, they make things very easy. If you don't like them, that's fine. Everything was read and proofread for the new Camel. I remember the week I spent working on those chapters.
I wasn't trying to be patronizing, but I bet I've worked with many more publishers than you, and I bet I've worked in more deadly situations than you. So, since we don't know each other, let's not fight about who's dick is bigger. :)
I've pointed you toward what Damian and Randal have said. If you think I'm a twit, that's fine, but the advice I'm passing on comes from them mostly. The problem with authority is that there are so many of them. :)
Have a look at http://damian.conway.org/Courses/EvenBetterPractices.html
Regards
Lukas