All of what you say is true. Perl does offer may freedoms that can quickly lead to disaster if you abuse them or don't know what you're doing - and since we're human, we *are* going to make mistakes and create disasters. IMNSHO, that's what makes programming so much fun - I never know when I'll do something spectacularly bad.

I think there is a tension between two competing forces, safety and power. Some languages are so safe, you can't get things done with them (that's an exaggeration, but they can be frustrating to use). They keep you in a sort of Barney-land, where there are no sharp objects and everything is purple. Other languages are like juggling chain saws. They're downright dangerous.

Perl seems to be a good compromise. It gives me enough power to get things done, without (always) erasing my hard drive. As you pointed out, Perl's attitude towards pointers has helped prevent me from executing my data, often something to be avoided.

What I like about Perl is that I have a choice as to how much discipline I'll use. I can follow good practices if need be, but I can also ignore them and play with fire. This works for me - a lone amateur - but it probably would not work for a team, without there being someone to enforce some rules. In cases where adhering to standards is critical to the project, Perl might not be as useful as some more restrictive language.

Much as I hate to say this, Perl isn't the best language for every project. In a large project with many programmers, you are likely to have a wide variation in skills, making it imperative that some order is enforced from "on high". If it's already built into the language (and can't easily be circumvented), then perhaps Perl wouldn't be as good a choice.

Still, I find the idea of Perl being "too rich" to be something like complaining that your job pays too much money. Oh, well...