|Now Perl 6 Is Raku, Perl 5 Can Be 7|
|Written by Nikos Vaggalis|
|Monday, 06 July 2020|
After Perl 6's renaming to Raku, acknowledging that it really is another language, Perl can now use number 7 without fear. It already has claimed the newly freed territory with the announcement that Perl 5.32 with more modern and sensible defaults is to be Perl 7.
That is, pragmas and features already being advised for years to programmers writing in Perl, like turning strict and warnings on, use 5.010 or importing Modern::Perl, are now going to be set by default when you start writing a new program in Perl 7.
However, care is given to backwards compatibility with just little things getting deprecated like not allowing the use of barewords for file handles or turning the indirect object notation off. Like Java, Perl has backward compatibility deeply rooted in its philosophy but for one, some things that are not relevant anymore have to go and for two, practices that are already being employed at large have to find their way into the language's defaults.That's with a twist as we'll find out later on.
Shortly after Perl 7's official announcement by pumpkin (that is, the person responsible for a particular Perl release) Sawyer-X at the Perl Cloud conference, d foy's new publication "Preparing for Perl 7" appeared. It details in depth what "7" actually brings, enables or disables, together with general advice on how to write effective Perl code. There, the introductory abstract sets the story straight and clears up any misunderstanding of what 7 is and isn't:
It’s more of an administrative upgrade so Perl 7 can set modern defaults and settings without forcing those on Perl 5.This jump is really a baby step to what’s coming up. It puts in place the structure and policy the perl developers will need to evolve the language.Much of the boilerplate of a modern Perl 5 program should disappear.
The twist mentioned before is found here; as d foy acknowledges the extreme backward compatibility of Perl 5, he goes on to state that:
But Perl 7 isn’t necessarily compatible with Perl 5. We will be able to tune it to work like v5.32, but at some point you need to buy into the new major version and leave Perl 5 behind. I’m a little sad as I write that because Perl 5 has been a dear friend for a long time.
Reading into it, someday when the conditions have matured enough to allow it, Perl 5 will be left behind, fully superseded by its newest counterpart. If that is the case, the major hurdle will be updating the thousands of Perl 5 CPAN modules to Perl 7. A Herculean task, indeed. But even under those conditions there's going to be:
"compatibility modes to assist you in the transition from Perl 5 to 7 (but not Perl 5 to 8)".
So while there's not an immediate need to go full on Perl 7, you should be planning for the future by adopting the best practices and advice found in d foy's book. He also has a shot at it with a Perl::Critic policy which checks whether you are already ready for Perl 7 to seemingly upgrade.Perl 7 aside, it's actually a good read regardless since it goes through analyzing the Perl 5 features which could find their way as Perl 7's defaults deprecating their counter-parts.Which are in use today, what they in fact do, how they are used and under which version they were introduced.
In that list we find "no bareword filehandles" enabled as default; as such the counter case of having bareword file handles in code will not be tolerated.Also having Signatures as default is going to deprecate Prototypes, and the reasons that "Indirect object notation" will be probably deprecated."Probably" is the key word here since Perl 7' official announcement, apart from the laying forward the general outlook and philosophy has not leaked any concrete info. So d foy taps on his vast experience to guess of what might be enabled or disabled, rating each one under a degree of confidence. Fortunately the book is published on LeanPub which means that as soon as new details emerge they'll find their way into a new book update.
In summary what it looks like Perl 7 is going to do is to :
It's important to understand that the issues arising from such transitions are not just Perl related, for instance the same dilemmas and portability worries are met in .NET framework's major transition to .NET Core.
But with the commotion around Perl 7 we've almost swept away the fact that there's actually a new Perl 5.32 version out, which carries some new bells and whistles. So in this version we find:
The isa Operator, a new experimental infix operator which tests whether a given object is an instance of a given class or a class derived from it.
some Security fixes :
and some internal Performance Enhancements. More on the version's Delta page.
In conclusion, Perl 7 is the mark that signifies quite a few things:
At the moment and in essence the act resembles the launching of a new car model in the series, sporting a new shiny body and catchy brand name but under the hood wearing the same old v5 engine with the exception of having some glitches patched and a couple of modern additions that make it more efficient.But this will not go for long, until the new type of engine arrives.Does this mean that the legendary Perl 5's Camel mascot will be changed too?
As far as the last point goes, "Break away from Perl 6 and Raku", in last year's "Perl and Raku Both Anticipating Newfound Glory" article, we had found that Perl 6 was looking to leave the Perl 5 baggage behind and that Perl5 would look to break free from the shackle of being blocked from releasing the next "major version" due to that Perl 6 is squatting on it.
Well that time has come.The renaming of Perl 6 to Raku is already paying dividends; both Raku and Perl have been freed from the strings attached and judging from the increased interest in both of them they are truly enjoying a period of newfound glory. Let's make it last.
Preparing for Perl 7 on LeanPub
or email your comment to: email@example.com
|Last Updated ( Tuesday, 07 July 2020 )|