I also think that part of Perl's mystique is that it's alright to sometimes solve a problem the "wrong way" for various reasons.
That's not specific to Perl - it applies everywhere. It's called
Worse is Better and means that there's no one single metric by which to measure the quality of a work. There are many, and what's better by one or several of them is not necessarily better by one or more others. There's usually one commonly accepted way that will get you a decent or good result in the majority of cases, but that isn't necessarily appropriate for all case. Weighing choices well here requires an observative and experienced programmer. To quote The Tao of Programming:
There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticised him for writing unstructured programs, saying: "What is appropriate for the master is not appropriate for the novice. You must understand Tao before transcending structure."
In other words, you have to understand the spirit and the reasoning of rules in order to be able to appropriately judge when to break them.
Makeshifts last the longest.
