You say it was a "bad language" for projects of any real size. But I've worked on large systems written in perl maintained by multiple teams. Perl wasn't the source of our difficulties.

The real issue was ugly code that was in the product when it was acquired--you can write 2000 line methods in any language if you are cursed enough. Believe me, if you do this, you will be cursed.

We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.

I'd go so far as to argue that the expressiveness and flexibility of the language was an asset that helped us in our refactoring. For example, we built instrumentation that took advantage of Perl's unusual semantics for dynamic "local" variables to create flexible instrumentation that could have log levels enabled based on the call stack--if you turned on aggressive logging in function A, it would propagate to A's calls into functions B and C, while other calls to B and C would be logged at normal levels.

Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context, but the dynamic scoping gave us the tools we needed to build something powerful with only a small amount of clear, commented code.