Perl is different philosophically from nearly every other programming language. Because there are a thousand ways to do a given task in Perl, it's vital to comment. No two Perl programmers would tackle the same problem the same way which, while great for hacking stuff together, makes it really hard for one journeyman Perl programmer to undrstand another journeyman Perl programmer's work, unless it's really tight, well encapsulated, and intelligently documented.

One of the best books I've ever read (and I've mentioned it before, so apologies to those who've been reading since the beginning) is The Pragmatic Programmer. It discusses several tenets of programming and talks about the hows (and mroe improtantly, whys) of good programming, basically, how to turn a journeyman programmer into a master programmer. One of the things it discusses is 'shy' code. Your function shouldn't try to handle every possible error under the sun. If it gets passed something it doesn't understand or expect, it should break, preferably by throwing an exception, and it should ascertain whether the arguments passed are 'right' or not before it tries mucking with anything, lets it leave a task half-finished. The authors (and others) call this "programming by contract," stating that every method should have a contract on what kinds of data it will and will not accept, and if that contract isn't met, it should break loudly, so the pgogrammer knows and can fix it before the problem starts happening on released versions of the code. Eiffel is a great example of a language that has contracts built in to the language.

Perl, on the other hand, requires discipline. While shy code and programming by contract are still entirely valid and useful in concepts in Perl (more so than in most languages, actually), if the programmer doesn't actually write it in, Perl as a language tries to understand anything you give it. It doesn't break easily (that is, it understands almost anything you throw at it, so while the code will easily break from what you intended it to do, it won't stop running or give any sign of a problem), and tiny changes in code can fundamentally change the nature of what Perl tries to do with a given statement. This is one of the reasons Perl is so great for writing obfuscated code, and the power this flexibility affords is presumably one of the reasons for banning perl from the ACM's annual programming contests.