Re: Announcing Perl 7

Im skeptical to this announcement. Is this announcement a carefull attempt to test the waters before going full steam ahead with Perl 7? Exactly how much support does this have from the community? My first impression is; I dont like this.

My work with Perl primarily consists of maintaining and extending a major object-oriented codebase. The codebase is only a year old, written from scratch by me, for my current employer. All code follows Perl 5 best practices. I use a lot of Moose, so warnings and strict is mostly on by default from Moose. While these new defaults would likely help me out, I would rather prefer to explicitly type out my "use" statements on top of each file.

I can also add that I dont take any issue with the possibility of having to rewrite portions of my code over time, to stay compatible with perl 7. Rewriting my own code for improvement is fine.

What I dont like is the potential for breaking changes towards CPAN modules, specifically mature modules that are "done", and may not be actively maintained, but perfectly safe to use.

I also dont like the potential for breaking linux/distro tooling, and probably being force to run multiple versions of Perl.

Comment on Re: Announcing Perl 7

Replies are listed 'Best First'.
Re^2: Announcing Perl 7 by hippo (Bishop) on Jun 25, 2020 at 11:24 UTC
I am somewhat skeptical too. 10 or 15 years ago this would have been great news and would have neatly side-stepped most of the negative attitudes to Perl arising from the schism. However, now that so much water has flown under the bridge and the naming situation was finally resolved last year the potential marketing gain from this is relatively minor. So for me it all rests on the backwards compatibility. Haven't we all seen how just a few minor incompatible tweaks in recent releases have caused significant numbers of problems? I'm think here mostly of the removal of '.' from @INC and the inability to write `for my $foo qw/bar baz/ {...}` which broke lots of existing and important modules, many of which remain unpatched. What I would like to see is a minimally-transparent way to have perl7 behave exactly like perl5 with no caveats. The only way I can see to do this is with an environment variable. It could be set once per server (and overridden per user/app/whatever) and then the job is done. If that can happen (and be thoroughly tested) then I'll be prepared to throw my inconsiderable weight behind it. The announcement by contrast only mentions a pragma (`compat::perl5`) which might be usable via $PERL5OPT (or $PERL7OPT more likely). So if we can set `PERL7OPT=-mcompat::perl5` then that should be manageable. It's still going to require extensive testing, of course. In the meantime, I will continue to forge ahead with perl5.	[reply] [d/l] [select]
Re^3: Announcing Perl 7 by choroba (Cardinal) on Jun 25, 2020 at 14:34 UTC
> it all rests on the backwards compatibility. Watch the announcement. Sawyer talks about people who need that and how Perl treated them in the past, and why it's time to change it. `map{substr$_->[0],$_->[1]\|\|0,1}[\\|\|{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^ARGV,3]`	[reply] [d/l]
Re^4: Announcing Perl 7 by dsheroh (Monsignor) on Jun 29, 2020 at 08:53 UTC
Yes, he does talk about it, but I can't say I found it terribly convincing. Particularly given that he characterized "people who don't use (or don't want to use) Perl any more" as the only ones who care about stability or backwards compatibility, and presumed that anyone doing current development wants whiz-bang new features to be added and on by default ASAP, even if it means they have to go back and fix their older code to account for it. Can't speak for anyone else, but I currently work with Perl code both as a developer and a sysadmin, I have no intention of reducing or stopping my usage of Perl, and yet I prefer to build on a solid foundation rather than shifting sands.	[reply]


Problems? Is your data what you think it is?
	PerlMonks