Most of the time you're maintaining code you're maintaining bad code, though, and it's pretty rare that I run across a perl program with "use strict" turned on. But if I don't see it, I at least know what I'm up against. The newer languages need a similar "A bad programmer wrote this" flags.
* You know who you are
It's funny, I'm working on a project for which a lot of the components were coded back in the mid '90s. The state of the art really hasn't advanced since then. The basic API (Xlib/Motif/Xcb) are nominally well documented -- you can find books and the library calls have man pages. Newer libraries and X extensions are a hodge-podge of largely-undocumented and generally incompatible API calls that take more work to integrate than they do to program in (Assuming you can find an example to work from.) The actual frameworks typically require you to drink all their kool-aid in order to use the framework. So I could go GTK+ or QT, learn their idioms and framework implementation details and that's great assuming I never want to change frameworks again and am willing to accept their quirks. And outside of QT, everyone (including motif/xlib) re-invent C++ badly with home-rolled type systems which often involve pushing strings around. Brilliant.
Somehow despite all this it still does what it does better than anything else I've seen. I'm not sure how this is possible, but there you go.
Even though there was a bit of a gap between the two schools' programs, 30 years ago you could get an introduction to programming and CS concepts in both of them. It seems like we've been back-sliding since then.
"No matter where you go, there you are..." -- Buckaroo Banzai