I hear people mummbling a lot about whether or not Perl is dying, but I think a better question is, “Is Perl perceived as old and crufty?”. I think the answer is related to the perception that Perl is dying and I think there may be something the Perl community can do about it.
First, let me define what I mean by the phrase old and crufty. When was the last time you cleaned out a communal refridgerator at work, church, or even at home? What did you find? Chances are you threw out anything that was obviously bad or wasn’t in a reusable container, but what about the questionable items? You left them in there because they might belong to someone else, and they might still use them. Even if you wouldn’t, they might. So they didn’t get cleaned up. That is what I call cruft.
Software developers don’t like cruft. In our own code, we have the ability to see what is used and unused and clean vigorously. It feels good to finish a rewrite or update to a system knowing that everything is nice and tight — shiny code. Or at least my perfectionist tendencies make me feel that way. So, when I see comments like this on the Perl 5 Porters mailing list, it makes me cringe:
But I’d be scared of making it in any stable release as I would be surprise if someone somewhere isn’t matching on it, and ignoring the current term.
The change being discussed isn’t necessarily even one I would be in favor of, but it is a classic example of the kind of talk that leads into the perception of a language being full of cruft that developers don’t like. I can understand how, through reading this type of comment, a person could come to see Perl as a language that is dying, not advancing, because the community is too afraid to make changes that would improve the language.
Now for some positivity: I think this perception can be changed, partly through the addition of quantitative analysis. For example, if we take CPAN to be a (non-random, obviously) sample of all Perl code, then we can check to see if any module on CPAN checks the actual value of a warning someone requested a change to. There are other Perl-based open source projects that can be grepped (or Ack-ed) through to quantify the potential impact of a change. Instead of stating, “someone, somewhere might use <blather> for <unintended_use>”, try to add to it, “… but there were no modules on CPAN that did, and neither do open sourc projects A, B, and C.” Perhaps we could even put together a set of projects and a tool to check outside of CPAN to make it easier to judge the impact of a proposed change.