Left Perl is 80% silliness and 20% truth. Some of that truth is "Why did it
take seventeen years to make
strict mode anything close to a
default in Perl 5?" and another part of that truth is "Sometimes you get nagged
about unrelated things when you ask a question about Perl".
Not that, of course, you can avoid nagging and insults and bad advice on the Internet in any discussion of programming languages. (Maybe if you only ever program Haskell and can call Brian O'Sullivan and Simon Peyton-Jones on the phone, but while I've done that, I'd feel guilty making it a habit.)
Here's the thing about experts. They're experts because they've made a lot of mistakes building real things and they've learned from those mistakes.
Do you know why most Perl 5 experts don't use inside-out objects? They turned out not to work so well in practice.
Do you know why so many good Perl 5 web developers use PSGI and Plack? They solve real problems elegantly.
Do you know why so many good Perl 5 programmers use automated testing built
Test::Builder? Because it works and it makes them more
Do you know why most good Perl 5 tutorials recommend the use of
warnings? Because they ask
perl to help you find likely errors and dubious constructs to
save you time debugging and to help you write better code.
Do you know how many times your average Perl expert has answered the question "Why isn't my program doing anything?" with "Why aren't you checking to see if your
open call succeeded?" Yes, that's an argument for changing Perl 5 so that it has better defaults. Yes, it's a usability problem. Yet it's also something that Modern Perl: the book gets around by recommending the use of autodie.
None of that advice excuses recommending
strict when they won't help, for example. I've
responded to several well-meaning posts on Perlmonks that say "I don't know
what your problem is, but you need to use
warnings" by asking what that would solve. These pragmas aren't
magic pony-colored bandages that make you vomit glitter and candy. (I think
that's the Ruby DSL generator called called Hipstr. Download from Github.)
None of that advice necessitates scolding people for not doing things your way. Way back in the mists of time (the late '80s), people like Larry and Randal posted "Here's how you'd do it in Perl!" to Unix administration and programming forae on Usenet.
The tricky part is when someone's obviously doing something the wrong way, say parsing context-free grammars with simple regular expressions. The expert has to find the balance between never condescending ("What is broken in your head that you would ever consider doing such a thing?") and giving the right answer ("Sure, it takes a few minutes to install and read the documentation and learn how to use this tool, but you'll get the right answer and spend much less time debugging frustrating errors none of us wants to debug.")
The novice, of course, has to meet the expert partway and acknowledge that asking for help means, of course, being willing to receive help. Otherwise you're wasting everyone's time. If you want to do that, at least have the decency to explain that you're doing so. (Posting questions without defensive coding squanders a community resource of altruism and good will.)
The best option I've seen is to answer a question directly, and only then explain how to avoid the problem in the first case. Sometimes that works.
I think one of the hallmarks of an expert versus a novice is that the expert knows full well that we always underestimate the time and effort of debugging and so we try to optimize to avoid the need to debug, while the novice thinks that all programming is a matter of juggling magic symbols until things seem like they work and you can escape with only a few bumps, bruises, and scrapes. Thus doing what's obviously extra work now seems like a terrible bargain because you don't know yet everything that can and will go wrong.
Then again, of course I'd say that. I enjoy the act of solving problems far more fun than the act of chasing down bugs (especially bugs I can and should have avoided.)