I gave a presentation on toxic code [OpenOffice] [Text] at the last Harrisburg Perl Mongers. The gist of it is that with perl, one isn't writing for speedy execution, but rather for rapid and correct development. Trying to keep your code succinct helps because the reader can concentrate on the logic.
The above is certainly readable perl, but when I look at the same code written in a different format:
I find it easier with the second format to realize that I'm not covering all the possible parameters. I should have error-handling code:
Because perl (or any Turing-complete language really) has TMTOWTDI, the easier that we can reveal the logic in our code, the easier it becomes to see the errors that crop up in rapid development. Part of the answer lies in documenting how your code works, part lies in sharing a style guide with the reader (why people harp on idiom so much), and part lies in coding succinctly.