Yeah, it's a bold assertion because it flies in the face of so many gripes from so many people for so long. Take the dailywtf. "I'm maintaining this horrible ASP programming" or "the guy who worked here wrote this in Perl". I wrote earlier about about the rot of Phoenix.PM as the entire congregation defected leaving only maintenance programmers.
These are programs that have been driven into the ground. Fear of refactoring, having the wrong people calling the shots, and the wrong priorities turned them into dung. This can happy in any language. Java has now been around long enough that programmers written in Java have descent into chaos. I've seen them. I've been hired to hire Indian programmers and I insisted on reviewing code before hiring a firm. All of them had terrible voodoo chicken bones code that in 100 lines foreshadowed million line voodoo code projects. And it was all in Java.
A program in any language in a historically badly run project evolves to somewhere past point of insanity. No self respecting programmer will try to continue adding features at this point, accelerating the descent when companies hire novices to try to extend the dung heap. The good programmers are put on maintenance; they won't do anything else, and keeping the thing running is a challenge.
But you know this. What matters is that the economics completely change when the project goes to hell.
The expectations for a maintenance programmer are calibrated to the difficulty of the project. None of the schedules, deadlines, SLOC, milestones, or other productivity metrics apply. There are easy bugs and hard bugs and sometimes the hard bugs live for a very long time time. Doesn't matter if it's COBOL, Perl, Java, ASP, or what. The maintenance programmer proved himself over and over again to his employer, so the lack of metrics don't matter. He's woken up at insane hours, worked late, and traced down insanely involved problems keeping the whole thing wedge. But... the language doesn't matter. The difficulty of fixing problems doesn't vary. It's a matter of definition: the project grew in whatever language until its unmaintainable, where ever that is for the language, and then the good programmers are just keeping the boat afloat.
Phoenix.PM is almost entirely composed of maintenance programmers. Programmers who like to write new code left a long time ago. And that was in other languages, for the most part: Java, C++, Python, Ruby...
But as a maintenance programmer, you're not writing code. And if you're proficient in a language, you can read the code. The idiom doesn't matter. The idiom doesn't make you more or less efficient at hunting action-at-a-distance problems. The hard bugs aren't in the expressions, they're in the interactions between parts of the system... or the lack of parts of the system. The fact that Perl's syntax can be confusing is completely irrelevant to maintenance programmers. Those are the easiest bugs they encounter in their job.
So, the conclusion that could easily be drawn from reading the dailywtf... that Perl is horrible, because there's so much horrible Perl out there... is a fallacy. Or that ASP is horrible because there's so much bad ASP out there... in both cases, I suspect the real problem is that programs overgrew their design, weren't redesigned and refactored, and the good programmers were forced into maintenance by business need.
If you're a good programmer who likes writing code, you're forced away from entire languages. You're suddenly unable to touch Perl, as an employee, because the only jobs are maintenance or else adding features to a completely fucked system, which you won't do. A few dozen companies mismanaging projects ruined the market for you.
And, conversely, PR won't do any good for Perl. The only thing to do is... start new projects. CPAN modules are good, but "Web 2.0", or "dot com" or whatever businesses. Make stuff in it that people care about. Create new projects that'll require maintenance, perhaps, and might be easy to maintain, but regardless *aren't* maintenance gigs right now.
-scott
Most of the jobs I've had recently here in London have been like that, too. Or maintaining and adding features to a completely fucked system while all the other people in the team are building a replacement in a completely different language.
