develooper Front page | perl.perl5.porters | Postings from June 2020

Re: Announcing Perl 7

Thread Previous | Thread Next
Wesley Schwengle via perl5-porters
June 28, 2020 19:03
Re: Announcing Perl 7
Message ID:
Hello all,

I am speaking as a user who was thrilled by the announcement of Perl 7. I'm not a core developer, nor do I maintain a lot of CPAN modules. For this e-mail just think of me as a random Perl developer who has seen the announcement.

I was absolutely stoked when you (Sawyer) made the announcement. I send out a few messages to co-workers during your long build to the actual announcement and was very pleased when you finally said those words: Perl 7.

Major version bumps make it possible to break backward compatibility and thus allowing new things in favor of the old. Perl 5 is still going to be supported for a lot of years. For all the code that is out there and those who wants to rely on Perl 5, they can use that specific version. I'm looking forward to be able to use the new shiny syntax stuff that isn't available in older versions of Perl 5. Perl 7 allows forward progression by ditching the mistakes of the past. It allows me as a user to pick a version of Perl that suits my needs. Need Perl 5 for that, great let's use p5. Want to write more modern Perl, p7 or up. I love it. And for me a big reason why there are major versions.

Most of the comments in this thread talk about backward compatibility with p5. I think this viewpoint is exactly what is addressed in the build up to the announcement. Newer stuff cannot be implemented because of the old stuff. We need to make a break somewhere. We are in this current position because the progression of Perl 5 has been hindered by the development of Perl 6/Raku (please don't see this as a bash against Perl6/Raku). IMHO it just created a situation where the let's not break older code in p5 became some sort of holy bible. Which is good, because that became the goal of p5, as it was in maintenance mode. Now with p7 we can change that goal. Implement new and shiny things, break with the old.

When I fire up the latest and greatest Perl I want to use all the (new) features by default and not having to enable them via `use feature`. It should become the default. Perl 7 allows that. I love the idea that `use feature` now becomes similar to `use experimental` (maybe not fully, but from a high level it seems this way).

I see comments about CPAN modules. CPAN is broken in a way. Old modules receive no security updates. When and if they are broken they aren't updated. Getting permission to take over the module is a painful endeavor. This move will also shake the tree a bit and we will see which modules break and which don't. Which ones are getting forked or get new maintainers to be used in Perl 7 and above and which will not.

Moving to Perl 7 within a year might be tricky if I read everything on the list. We as a community need to decide:

1) What the current and future goal is of p5.
2) What the goal is of p7 (and up).
3) If we are going to stay backward compatible for the next decade(s) with newer perl versions (7 and up).
4) If we want forward progression in favor of keeping 20 year old perl 5 code alive.
5) If CPAN needs to support unsupported perl versions.
6) Does p5 support p4 and if so (I don't know. And if it doesn't, why would we want p7 to support p5?) do we want p7 to support p5 and lower?
7) Do we want to maintain two different version if p5 and p7 cannot reach agreement on backward compatibility?

Once these questions have been answered and a consensus has been found we can move forward.

A few questions:
* Is there a public roadmap of what p7 will bring us and what we can expect from it?
* Where can we file feature requests for p7?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About