I believe that the problems of unmaintainable Perl code have less to do with individual programmers who collaborate on projects than the lack of company-wide standards of the organizations that employ them.
For example, I'm an engineer, and when we make drawings at my company, we follow a template. Object lines are white, hidden lines are green and dashed, center lines are red and dashed differently, and dimension lines are a girly pinkish color that print with slim, slender lines on paper. Of course anyone can make drawings in any color they choose (TIMTOWTDI), but if I went to work on Monday and screwed with the colors in my drawing, all the other engineers that work on that drawing will get awfully confused, and I'll hear about it all day. So you see, it has less to do with our drafting software than with company standards.
This is directly analogous to the Perl maintainability issue. Had Sally and Bob been trained to at least agree on a set standard for creating objects, then the communication issues (which maintainability really boils down to) would have been minimized. In fact, I believe that Perl's boast of TIMTOWTDI opens up the field for Sally and Bob to seek methods of coding optimized for their specific projects and to choose the best option to use as a standard. Indeed, this even smells of Continuous Improvement, which I'm sure my Industrial friends are sure to enjoy.
I do not believe that these standards should be set by the creators of the programming language. The rules of the language should be open enough for any programmer to choose their own favorite method of coding. That's why I chose Perl in the first place. When I learned that I didn't have to declare variables if I didn't want to, it was like love at first sight. But don't think for one instant that I let my variables run amuck without clearly defined scope, like digital free radicals in a pristine body of code. It's the freedom to choose that was, and still is, most important.
