zlacker

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.

>>daotoa+(OP)
Interesting to hear that perspective. But you touched on where I'm coming from:

> The real issue was ugly code that was in the product when it was acquired

IME, this was the norm for Perl projects, not the exception. And you explain the reason for that:

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

Yes, it's true that a disciplined, mature, skilled team can write good code in any mainstream language. But in practice, there are far more teams that lack enough of those qualities, that using what I'm calling a bad language will contribute to them producing hard to maintain, buggy code.

If you're defining a subset of a language as being good, you're proving the point about the overall language not being good. This is why Perl failed - because its real-world use more often than not produced poor outcomes.

> Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context

That doesn't sound like the right approach - it sounds like you really want the opposite of a singleton. In most languages, you'd just pass a different logger instance, either as an argument or in an object field.