What's an example of a language that's as bad as Perl, that's used as widely as Perl was, that's still in use today?
Perl died because everyone who mattered knew it was a bad language, knew it had to undergo drastic changes, but that essentially meant implementing a new language.
Perl 6 was the symptom, not the cause.
---
Note: by "bad language", I mean bad for anything much beyond the kind of thing you might use awk for. It was bad not because of subjective aesthetic issues, but because it was difficult to maintain non-trivial code bases. Its "write only" reputation was well-deserved - the original author of a non-trivial Perl program might be able to maintain it, but once a team is involved, forget it.
PHP? I don't know how widely it's still used, but I'd guess it's more widely used than Perl. Also, PHP is not "as bad" as Perl. It's much, much, much worse. It's Perl without the charm.
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.
> 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.