Perl's history shows two spikes in adoption rates. The first came early in its life, when system administrators realized that Perl could replace homegrown and ad hoc polyglot scripts written in shell and AWK and Unix command line utilities. The second came several years later, after the WWW and CGI revolutions, when programmers recognized that Perl made a great language for dynamic web sites.
Perl has expanded into other application domains, but it's still a bicameral (not sorry for the pun) language. I've pitched this tent clearly in one camp, but I want write clearly about the other camp and why it doesn't concern me.
Stability and Predictability
Many Perl-using system administrators fit into this camp. They have a lot of mottos, such as "You can't break existing code!" and "Slow and steady change is fine!" Upgrades should be infrequent and predictable. Some of these people have code they wrote a decade or more ago that runs, unchanged, on the most recent version of Perl.
The Perl 5 development process has catered to this group since its inception.
The goal of this group is to ensure that old code -- never touched -- always works the same way. It's easy to mock this position, as some of its adherents are truly crazy in expecting that people running a decade-old release of Perl should expect that a CPAN module written in 2009 will install and run successfully, but there's some validity to this position.
Take, for example, the all-too-common example of the Mac OS X update breaks Perl story. Perl is useful. Apple distributes several utilities which rely on Perl. When Perl-savvy developers make routine changes and perform routine upgrades, the OS gets caught off guard. Something changed. Please note that this problem is not particular to Apple. It's affected many other operating systems and distributions, both proprietary and free.
The problem with this approach is that it's fundamentally incompatible with the other approach. Expecting that nothing will change when you change something is a good way to discover that making a change may, in fact, change something.
Again, I'm mocking an extreme position. I do find it reasonable to preserve some degree of backward compatibility for a reasonable period of time, but that line of thinking leads to the question "How do you solve this problem?", which I'd like to delay until the next entry. The real point of contention between these two camps is on how to deal with change.
(This question is at the heart of Masterminds of Programming -- Powell's affiliate link -- which asks it of the designers of several influential programming languages.)
Improvement and Abstraction
The other school of thought believes that change is necessary to improve the language. The Perl 5 development process has made some concessions to this view over time as well. The module system and the CPAN itself demonstrate the value of a loosely-organized and self-organizing language extension system.
The goal of this group is to improve the language and its ecosystem based on feedback from real-world usage. What's good? What's difficult? Which changes would make the language and its libraries easier or faster or more pleasant or more powerful? Which new niches can and should the language target to improve the lives of programmers or gain new ideas?
Another good question is "Are programs getting easier to write, over time?" (Try Moose for an obvious improvement over Perl 5's default OO.) A scary question is "Are the internals getting better over time?"
There are very good reasons Perl 5 has trouble attracting new developers, and they're the same reasons that Perl 5 doesn't have a JIT or an advanced garbage collector or ports to other VMs -- not that I'm bitter. (I have patched the Perl 5 parser, however. If that doesn't give my authority some appeal, I'm not sure what would.)
The Real Question
No one sits completely in one camp or the other. They're poles. This is a spectrum. No one seriously argues against fixing any bugs because people might be relying on them. (Some people seriously argue against fixing some bugs, because someone might be relying on them, however. Drives me crazy.)
My stance should be obvious. I believe that it's possible to design and build a working, reliable system which undergoes constant improvements at regular intervals such that upgrading frequently is boring and predictable. Other projects have done this. Other projects in the Perl ecosystem have done and continue to do this.
The most important question is not "Should change occur?" but "How can change occur to minimize disruption to the first group and meet some of the goals of the second group?" I have two practical, technical details to explain in my next two entries.
