perl514:

No, you should leave it on. When you're learning perl (or any other language for that matter), it's good to write in a simple straightforward manner. As you get more experienced and learn more idioms, you'll start writing tighter code.

It's just like talking about a new field. At first you find the language that the experts use hard to understand, and you have to use normal English (or whatever the local language is). As you get more involved in the field, you start picking up the subtleties of the jargon used, and you become familiar with it. It's a gradual process, and you're not usually aware of it. Until someone new comes up to you and starts talking and you become aware of what you learned.

So your node will be immediately useful and easy to modify for someone newer to the language. And the tighter bits will help serve as a Rosetta Stone for people learning more advanced bits of the language. Most of all, have fun with it.

If you're really wanting to learn the weird bits of the language, play with the obfuscations & golf challenges.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Hi Roboticus,

Thank you for the encouragement. I have posted and updated version of the script.

Perlpetually Indebted To PerlMonks

In addition to what roboticus said above, golfed solutions are often not what you would want to use as production code. Golf is like a workout for the mind. It keeps you in shape, but is not the real purpose (unless you make money by lifting large amounts of weight and putting it back down).

Golf solutions explore the corner regions of the language where few people explore. The creativity required to produce some of these solutions make them unacceptable for use in anything more than an exercise. When writing production code, you are writing:

• to codify an algorithm
• to effectively communicate that algorithm to future maintainers, including yourself