I remember seeing a fair share of debate concerning the naming of the next stable version of Perl 5. It would be a shame to let all of Perl 5 die simply because of backwards incompatibility. Specialy as Perl remains a highly powerful language with very good readability. (Stay out of it Python).
Given Perl 6 is forking away from Perl 5 (not entirely backwards compatible), several possibilities come up:
- Perl 5 versions converge to 6 (5.99999999…)
- Alternate version naming convention (perl 5 becomes perl 7, 9, 11 etc. & Perl 6 then becomes 8, 10 etc.)
- give Perl 6 a different name
Each solution has its many disadvantages:
- Dificulty to quickly define version number.
- What happens if another fork commes along during Perl 17? Perl 10?
- Extreme difficulty to decide upon a name. Perl is afterall, more than a programming language, it is also the community of people who program in said language.
I have heard (or rather, read on IRC) that Perl6 is not deployed as stable yet, as it doesn’t (currently?) support the entirety of CPAN. But, if there is no backwards compatibiliy, there is no way for it to support (most of) CPAN, as it will be 2 different languages.
What I would like to see happen:
– A portability module in the Perl 6 core. the capacity to add “use 5” in Perl 6 code in order to allow for backwards compatibility, without being automatically used, in order to avoid the overhead.
After reading through the following: read this, I see that the issue is already being addressed in a very optimal manner. The only thing that I was unable to see adressed there, was the capacity to have the system use both Pumpkin Perl AND Perl 6. Sure, you could set an alias “pumpkin” in your bashrc to run Pumpkin Perl, one liners, but that doesn’t really help if your system happens to use both for various reasons.