Several recent posts (more here and here) discuss whether Perl 6 is an impediment for progress of Perl 5 and debate remedies involving changing the name of one or the other. The problem I have with these debates is that they sideline the realities of the current situation in favor of romanticizing a counterfactual.
The counterfactual is this: "If Perl 6 never existed, then Perl 5 could bump itself to Perl 6 NOW in order to signal a backwards-incompatible break from the past."
If the counterfactual were true, I believe this could happen, even with the limitations of the Perl 5 development process we have today. Perl 6 (as it actually does exist today) is revolutionary design, not evolutionary design, but that doesn't preclude an evolution of Perl 5 that significantly breaks backwards compatibility.
Without recommending any particular change, here are some examples of things that I think could be possible, just to give a sense of what evolutionary (rather than revolutionary) changes could attempt:
- Replacing
eval BLOCKsyntax withtry BLOCK - Removing of Unix-specific user/group functions and similar cruft
- Eliminating of indirect syntax
- Replacing method call arrow
->with the shorter (and more widely recognized) dot/period character (and finding a new concatenation operator) - Eliminating version objects and v-strings
- Replacing (frequently misunderstood) function prototypes with function signatures
Those are just ideas off the top of my head, but I hope it's easy to see than any of those break enough existing code as to make them very difficult to envision being added to any future release of Perl 5. However, if the counterfactual were true, then there would always be the option of making a clean break to "Perl 6", ensuring that there is no automatic expectation of backwards compatibility.
Even if the counterfactual were true, making such evolutionary changes would not necessarily be easy. It would require a Pumpking (other than Larry Wall) to play language designer for Perl 5 and to push the Perl core developer community into a rough consensus. But hard does not mean impossible.
However, with the reality of Perl 6 as it stands, even a name change by Perl 6 ("Camelia" was one suggestion) doesn't help Perl 5's evolution. Given the expectations that have been set for Perl 5, it seems unlikely to me that there would be broad community support for Perl 5 evolving into Perl 6 if Perl 6 were renamed. "Hi, we promised you Perl 6 ten years ago, but it's not ready for production, so we're going to call this other thing Perl 6 instead." I don't think that's great for external perceptions, either. What then? Jump over Perl 6 straight to Perl 7? I don't think that would be well received, either.
For Perl 5 to evolve in ways that are significantly backwards-incompatible, I see only two realistic options:
- Rename Perl 5 to something else, with all the associated branding and marketplace traction issues that would cause, but with the ability to make a major version number bump to manage compatibility expectations.
- Increase the speed of mutation of Perl 5 so that Versions 16, 18, 20, etc. become bigger departures cumulatively than we ever saw with Versions 6, 8, 10, etc., and become much more ruthless about setting future compatibility expectations.
(I suppose an interesting variation on the first way would be for Perl 5 and Perl 6 to be renamed simultaneously. I could see that having some positive opportunities for branding and marketing.)
The status quo alternative is for Perl 5 and Perl 6 to continue as they have been, slowly chugging along on their respective tracks. Perl 5 will continue to put backwards compatibility over evolution and won't see substantial new features added or old mis-features cleaned up. Perl 6 will continue to push towards some sort of production readiness.
For some (perhaps many), the status quo is ideal. For me, I would find it rather boring to be a part of.
So -- let that be the real debate in the Perl 5 community: compatibility or evolution? Names and version numbers are just the means to an end.