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


in reply to Best practice or cargo cult?

One of the things that TheDamian emphasized in his talk at TPC that became the book PBP was that the rules he was espousing were the rules he thought were important. He didn't expect everyone to agree with every one of the items, but that he wanted each person to make a conscious decision about what they wanted to follow and stick with it. Having a set of default behaviors based on choice rather than habit was better than the opposite.

So best practice is having a consistent behavior and cargo-cult is doing something because someone else told you to, without understanding the reasons yourself.

John

Replies are listed 'Best First'.
Re^2: Best practice or cargo cult?
by Juerd (Abbot) on Jun 20, 2006 at 21:16 UTC

    You summarized my major gripe with this otherwise great book.

    I feel it should be titled "Damian's Best Perl Practices", not "Perl Best Practices". Damian's opinion is considered authorative, and already it is common that people who know little about the language automatically resolve any discussion in the direction of PBP. Effectively, this book has at least partly destroyed the freedom and intellectual discussion that has always surrounded Perl in business use.

      Until PBP, there was not a single Perl book which had focused on writing better standardized code. Most of the books that I have seen are little more than an overview of many subjects and do not go into any depth. A good example of this is Advanced Perl Programming, Second Edition. From the table of Contents, for Template Tools (Chapter 3) it introduces,

      1. Formats and Text::Autoformat
      2. Text::Template
      3. HTML::Template
      4. HTML::Mason
      5. Template Toolkit
      6. AxKit

      You have given them 6 options but not much insight into what problem they are going to solve. You could argue that a person should look at them all and make your own decision. On the other side, you have not given the user information on how to develop an application or increase productivity. This sort of material is at best shallow and useless after reading it once. (In comparision, I will go back and look things up again in PBP periodically).

      Damian got an overall concensus on his thoughts and solutions from others and wrote a book on it. Damian Conway did a lot of the work but he did not do it alone. The thing that PBP actually provides are real solutions to common problems (example: use Readonly vs. use constants). That is something that other books just don't even address and leave me turned off from even looking at them.

      To imply that somehow he has destroyed discussion because of the title and being an authorative figure is being dishonest. There is nothing there that prevents you from writing your own book except your own motivations, skill as a writer and a someone to publish your book.

        Again I state that PBP is a wonderful book. That doesn't mean I agree with everything in it. Sometimes, like on the issue of using /smx by default, I even think that PBP gives bad advice.

        Damian got an overall concensus on his thoughts and solutions

        Concensus requires much more than any single person...

        To imply that somehow he has destroyed discussion because of the title and being an authorative figure is being dishonest. There is nothing there that prevents you from writing your own book except your own motivations, skill as a writer and a someone to publish your book.

        I said that PBP at least partly destroyed freedom and discussion, and stand by that. It's become much harder to program in your own favourite style. Many businesses adopted PBP fully because it's much easier to pick a book than to think about things yourself.

        I've never had to defend that I don't use /xms, I've never had to defend that I don't use inside-out objects, I've never had to defend that I use normal Perl constants, I've never had to defend that I want to keep source filters out of production code at all cost. But now, all these things require a lot of discussion in which usually the conclusion is predetermined because it's printed in a book written by an authorative person.

        I believe that this was never Damian's intent, but that doesn't change that PBP has in fact taken away some of the Perl fun for me.

        If I wanted to align my code along such strict and sometimes silly guidelines, there are other programming languages that would be much better for me.

        I think a book like PBP is really great, but that PBP takes things too far. WAY too far. But it's still a wonderful book that many people can learn a lot from.

        Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

        Until PBP, there was not a single Perl book which had focused on writing better standardized code.

        Although I agree with your overall point, I must stand up for one of our own, Merlyn, whose work with Hall on Effective Perl Programming was a great help to my Perl coding skills. It's a book very similar to PBP in a number of ways, although it's not as comprehensive; it's sort of (in my mind) a cross between PBP and Perl Cookbook, and (if I recall the latter's pub date) pre-dates both.

        ----Asim, known to some as Woodrow.