|
in reply to Re^3: Best practice or cargo cult?
in thread Best practice or cargo cult?
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.
|
Re^5: Best practice or cargo cult?
by TheDamian (Vicar) on Jun 21, 2006 at 21:07 UTC
|
Damian got an overall concensus on his thoughts and solutions
Concensus requires much more than any single person...
Starting at page xx, PBP lists over two dozen other people, many of them very well known and highly regarded in the Perl community, whose advice and feedback I sought as I designed and wrote the book. Most of them read the entire book before it was finalized; most of them argued numerous suggestions at length and in great detail; most of them convinced me to change one or more of the guidelines in some substantial way.
What's in the book is the concensus of a large number of very talented and highly experienced people. People like Abigail, chromatic, Paul Fenwick, Uri Guttman, Trey Harris, Steven Lembark, Andy Lester, Jacinta Richardson, Randal Schwartz, and Peter Scott (to name ten at random). Like you, they didn't always agree with every solution I suggested. But they did concede that the issues I raised were genuine problems for many Perl programmers; problems that demanded consideration, discussion, and ultimately the adoption of some standardized and reliable solution.
I encourage you--and everyone else--to criticize and debate the guidelines I've suggested. It is, however, incorrect to imply that those guidelines aren't the result of extensive consultation, collaboration, and collective experience.
| [reply] |
|
|
Concensus requires much more than any single person...
Starting at page xx, PBP lists over two dozen other people
My remark was meant as a linguistic one, but I can see it can be interpreted in multiple ways.
It is, however, incorrect to imply that those guidelines aren't the result of extensive consultation, collaboration, and collective experience.
I never meant to imply that. My apologies if it did appear that way.
Still, I do wonder if defaulting to /msx is concensus or the opinion of a few. I've certainly never encountered many people expressing this opinion before PBP came out.
| [reply] |
|
|
Still, I do wonder if defaulting to /msx is concensus or the opinion of a few. I've certainly never encountered many people expressing this opinion before PBP came out.
Like many good--and bad!--memes, it certainly seems to have started with one person (i.e. me). Like you, I had never seen anyone else suggest permanent /xms until I started using it.
But I do think that the idea has spread rapidly and is become a consensus best practice, not simply because it's Damian who advocates it, but because many people are finding it valuable, finding that it improves their coding and simplifies their maintenance.
Of course, that's not to say that there aren't some people who do just blind adopt it because I said so. I'm sure there are such cases. Unfortuately, there's nothing I can do about that. I spent most of the first chapter of PBP pleading for readers to assess, consider, try, and then critically evaluate my advice, but not everybody has the will, the interest, the time, or (frankly) the capacity to do that. For those that don't, at least they're blindly adopting a convention that works, that is consistent, that is less error-prone than the Perl 5 defaults, that has few drawbacks or downsides, and that many more clueful Perl folks agree is a good idea and have adopted themselves.
I fully accept that other clueful Perl folks, such as yourself, don't like the convention, and find it annoyingly constraining or less expressive or fun-diminishing. However, I'd point out that in many development environments there are good and valid reasons to restrict the freedom, expressiveness, and playfulness of individual developers, not the least of which is that not all developers in the environment are sufficiently flexible, literate, or self-disciplined to cope with the freedom, expressiveness, and playfulness of their more accomplished colleagues.
| [reply] |
|
|
|
|
| |
|
|
|
|
