in reply to Perlmonk's "best pratices" in the real world

I'm a little bit on the fence about what to tell you, since I've made good money as a consultant fixing other people's broken Perl code. What was broken about it? It was impossible to change or debug because it was written in the quick-hack style you are describing. Eventually, some managers would get fed up with the difficulty they were having making changes or fixing problems. Then they either hire someone like me to fix it, or declare that everything is going to Java.

There's the rub: you know how people who don't like Perl are always bitching about how they can't read it? This is why. And the more people write crappy Perl code, the more it reinforces the notion that Perl is only good for writing crappy code.

Why do we recommend solutions involving strict, templates, tests, etc. to people on Perlmonks? Because we tried them, and they worked really well. Becausse unlike my consulting gigs, no one pays me to answer questions on Perlmonks, and I get tired of helping people with something that would have been instantly obvious if they had used strict.

On the whole, I think that reminding people of what has been shown to work is a positive thing. I might choose to extract data from HTML with a regex, but it doesn't hurt anything for me to know that many people think a parser is the best way to do it. It might even help.

  • Comment on Re: Perlmonk's "best pratices" in the real world

Replies are listed 'Best First'.
Re: Re: Perlmonk's "best pratices" in the real world
by mpeppler (Vicar) on Nov 13, 2003 at 16:28 UTC
    This pretty much sumarizes my take on this issue as well: perrin++

    Michael