Why I
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
around Test::Builder? Because it works and it makes them more
productive.
Do you know why most good Perl 5 tutorials recommend the use of
strict and 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
things like 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 strict and
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.)
"The tricky part is when someone's obviously doing something the wrong way [...]"
And also finding the fine line between wrong in the sense of "broken and will not work," and wrong in the sense of "a very bad way to do it that should be discouraged, even though it'll work."
The other day I answered a question on PerlMonks, where a guy was looking for lines in file1 that matched lines from another file. He was doing it with nested loops, looping through file1, and then for each line from that file, looping through file2 and comparing each line. His question wasn't about whether this was a good idea, but regarding something else that was actually broken in the code. His nested loops would work; they were just a horrible way to do it.
Any mildly experienced Perl programmer looks at that problem and instantly thinks, "make a hash from file2 and then loop through file1 checking for the existence of keys in the hash." That algorithm is so superior, and perl's hashes so suited to it, that it's automatic. I felt a duty to explain that to him, but since his question wasn't actually, "Tell me what a lame noob I am at Perl," I put it as gently as possible, like, "Here's a way to do it that's much more Perlish and will work better for you."
It does get frustrating to help people when half your answers consist of, "Let Perl tell you the problem by using strict, warnings, and error checking." It is painful to keep seeing code like 'open(FILE,"<myfile.txt");while(<FILE>){'. But answering the same basic questions over and over is part of teaching, whether you're doing it on a web forum or in a classroom. I wrote code like that too, when I was getting started. I like to think I got better.
To some extent, I think we're victims of Perl's success and staying power. Perl newbies are still turning out 1995-style code because the books and tutorials written back then were so good that people are still learning from them! If (God forbid) people are still coding in PHP 17 years from now, I doubt they'll be learning from the mess of code snippets that make up php.net. But can you learn to be a productive Perl coder from the camel book today? Absolutely.