It was bound to happen.
While I don't actually work in Perl these days, and not by choice, I still keep an eye on the community. The language is chugging along nicely. Perl 6 is out, so at least that joke has died down, features are being added, some beneficiary, some not. All is well in perland.
Then the news dropped. Perl 7. I was very interested. More so when I realised that it was a rebranding of the latest Perl. First, let me say one thing right off the bat. It's a good call. I'm all for it. In fact, I'm so all for it that I called for it in a post from 2011. At the time I suggested using codenames like Apple and others do, or to rebrand Perl 5.14 (at the time) as Perl 14 like Java did.
Here's why I thought, and still do, that this "rebranding" is a Good Thing:
It bypass the whole perl5/per6 story. With perl 6 not being perl anymore and Perl 5.32 being rebranded Perl 7 the community will be able to finally move past this whole deal.
It shows progress. Many people don't care for "minor" releases. The corporate world got everyone used to "major" releases. In the real tech world you can have a project still not in 1.0 for 20 years, but sadly, most people making the calls are not from this world.
It allows for improvements. We all know that many elements of perl 5 are unmaintainable because changing them will break backwards compatibility. And I'm not referring to the many funny outcomes that will occur once "use strict" is turned on by default, but to actual internals changes.
The perl world is filled with applications using and abusing direct calls to perl internals in many clever and amazing ways. Sadly, this has haunted the perl development for ages, preventing any actual work that might change, improve or alter the actual lower-case perl. Now this can be addressed. The perl 7 announcement means that if you have an existing project, you can't just pull the new perl and it will run, whatever the reason.
The best thing, in my opinion about this, is that finally new ideas can be implemented. Everyone would love to finally have the great ideas for OO perl in the core, and with breaking backward compatibility, they can be implemented without having to tip-toe around whatever internals can't be touched. The reference model can be reworked, without having to resort to stuff like the fugly postfix feature that the only good thing I can say about it is that it makes the old way seem actually elegant.
It's still going to be good old perl, that old, reliable car, but it could now have finally some of the more clunky parts of the engine replaced, and the AC unit can now finally be taken off of the roof and placed under the hood.
Obviously, not all is going to be rosy. There are a lot of people who don't understand why this is a good thing, or a thing at all. You learn to be wary of what is a pure marketing ploy, and this does have all the signs of one, despite, in my view, also carrying a solid technical merit.
There are who will argue that perl's commitment to backwards compatibility is why they were using it in the first place. Many will argue that this will give many *NIX distributions the final excuse to throw away perl support because perl 7 will break their tools and cause a problem and fragment the upstream etc. The Python 2 to 3 process will probably be mentioned (partially incorrectly, in my opinion, but even so, its something to considered).
Another thing to remember is that many of the people on perl5porters are those who created applications that perl7 will break, either because of legacy or because they used their internals knowledge to create all those uses and abuses for their own modules and systems. Many infrastructure-level modules do that. Many essential tools use perl and they will need to be addressed. Programmers will be mighty pissed if they "upgrade" to perl 7 and all of the sudden their DB integration crash and git doesn't work.
It's not going to be a simple move. But it is a necessary one. The decision to make perl 6 condemned perl 5 to a decade of stagnation. I believe the decision to make perl 7 will allow for (at least) a decade of forward-looking development. And I'm all for it.
After all, I've called this almost 10 years ago.
Because sometimes you need to bash your head against the wall until either you, or the wall, give up.
I'd be happy if they sped up Perl, particularly on calling subroutines and methods. We used perl for ETL handling files with hundreds of millions of records. Learned early on that Object Oriented code was way too slow. Even calling subroutines was too slow - I wound up ripping out what subroutines were already being used and inlining the instructions. Part of the problem was our company doubled in size but still expected our processing to take the same length of time. Some kind of macro capability to inline commands would also be nice.
I still use Pearl for some little things, but unfortunately I don't use it professionally either. A good reminder of the good old days.