I think most people using Perl for anything non trivial (eg, large web app with Catalyst) are unlikely to be changing their version of Perl without a good reason, and very few people are starting large Perl projects now days. My day job is working on a fairly complex app running 5.28.1, we have no desire to change the Perl version without a very good reason to do so.<p>I find this post a little unsettling. It seems like even the Perl community is unsure why they are doing this.<p>At least for me, Perl === Perl 5 (and probably always will). It works, and it's ecosystem is very mature.
I like Perl, and I think that changing the defaults is a sane thing to do. Starting a new script with dozens of "use strict", "use v5.30", etc is less than ideal and it's easy to forget something and shoot yourself in the foot. Almost 30 years will pass between Perl 5 and 7, and going back to the old values is just a matter of adding a few lines at the beginning of your old script. It's not a mess like the whole "Python 2/3" ordeal that was deeply more complex and painful.<p>Heck Perl in the last 30 years has been even more stable than C. I remember when gcc and clang switched from a default of GNU89 to GNU99 and it broke several packages who didn't set or check for the right flags; nobody bitched about it and just went on to fix their Makefiles.
Had a chance to work with Leon on the TestAnything protocol. Really great guy to work with.<p>>I don't know where we're going. I'm not even sure if this forking is good or bad in the long run (it could be good if managed well, but so far it isn't). And that terrifies me.<p>Hopefully this new version will make Perl easier for newcomers. But maybe before the final decision they will find a compromise solution where some old features may be dropped, while making it not-so-hard to migrate Perl5 to Perl7.
Wait, hold on. They're talking about Perl7. Is this the next version after Perl6, which is called Raku? Or is Raku already completely forked off and now they're talking about another fork of what remains of Perl?
So now that Perl 7 wants to actively remove backwards compatibility from its culture, where are people to turn now for stable/non-moving scripting languages?
Exactly. "7.0 doesn't aim to bring new features, it doesn't enable us to do anything that isn't possible without it (other than not writing that guard). Instead, it aims to change perl culture as we know it. The whole point of perl7 is radically choosing approachability over stability."<p>Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide. They even broke back compat in 5.30 with the change of attribs on subs, which is heavily used outside of perl5, but not at all within. Totally unjustifiable.
Much of the problem is that people see things like Perl or Python as holy grails that must not be changed or questioned. This stance mainly comes from these languages having been installed by default on almost all Unix platforms for the past 25 years. That's quite a long time to bludgeon people into thinking that these things are sacred and fixed.<p>Computerists should not be afraid to try something new at every turn, and then reject that something if it does not measure up. In the short run, change is often scary, but in the long run it is the only way to survive.
a similar argument is going on in c++ community - whether to value stability or performance.<p>one thing that always struck me is that the number of developers of X language is some factor times the number of developers at the point in time when it first had a strong community. if that factor is greater than 2, and it usually is, then to me dividing the language into two distinct dialects with different values makes sense.
If I understand right, all they are doing is changing the per-script, per-module defaults to enable current language features, instead of having most features since about 2005 disabled by default.<p>Perl5 has a very strong position on backward compatibility. Even when they change behaviour or add new syntax, that's disabled by default unless a script or module explicitly asks for the new behaviour.<p>Each significant feature can be switched off or on per module. Even if the main program turns on features, they remain off for the modules used by the main program.<p>So as far as I can tell, the proposal is just to change this default, so that modern Perl5 features are available to new code by default, instead of having to be explicitly requested, and there's no radical change or incompatibility planned for v7.<p>That's a change of compatibility-first culture. It means scripts which don't specify what they do and don't want will indeed break with newer versions, occasionally. However Perl5 changes quite slowly, and it's unusual for something new to break something old anyway.<p>But it should be easy for scripts to specify what they want.<p>If there's a "no v7" directive that should be enough at the start of any script or module that wants to keep working while being insulated from future changes. That's not much different, in practice, than what they already have to do to ask for features they do use.<p>Another idea would be to have two search path directories, with different defaults in each, and modules install into the appropriate one according to module metadata. This would allow existing, old modules to carry on working in v7.
I really don't get any of this. Here's the full picture: Larry Wall mostly gave up on Perl 5 in 2000 and announced the next release would be "Perl 6". A few small updates happened to perl 5 up until 2002. Larry started working on Perl 6, forever leaving perl 5. Perl 5 goes stagnant for 5 years, meaning it had no updates released for 5 years. During this time, droves of people picked up python. Perl 6 was no where near complete in 2007, and a small team of devs pushed out perl "5.10" after a 5 year hiatus.<p>Perl 6 was finally released in ~2018 but by this time no one cared. The perl 6 team feels because of the name 'perl', people aren't adopting this new language, so they change the name. And now a year later, the small perl 5 team is wanting to take perl into the modern age by breaking backwards compatibility. It makes no sense at all, that was the job of perl 6.<p>It would no different if I started complaining about python 2 not getting any updates and then making a plan to better improve its parser and object model and break backwards compatibility and bring it into the modern age. Python 3 already did that, so like what the heck are you doing???<p>And then the comments from the perl 7 supporters... saying things like we can either "fight or die" or doing nothing is "certain death" but the alternative is "uncertain hope". I just don't see the point in fighting for something the original author of gave up on over 20 YEARS ago.<p>I've stated my points [0] before on how companies that stick with perl 5 do so at their own demise. They get cultured into a train of thought where updating software is seen as bad and unhealthy. And if they are a consultancy, their downstream customers also get cultured in to never having to worry about "updates" and/or paying for updates. So then long term contracts with said customer only take into account the cost of feature enhancements instead of "maintenance". So then it becomes impossible to move either consultancy or customer off of the "perl platform" because going to something like django, while a big cost in its own right, would involve a different long term contract that would require paid support and downtime for future django updates/releases. Never mind that finding devs would be easier (and probably cheaper), and the fact that django gets regular security audits and has a much larger plugin/library support ecosystem.<p>Anyway, to each their own. And godspeed to the perlings out there, I just don't see how any of this is worth it...<p>[0]:<a href="https://news.ycombinator.com/item?id=23633478" rel="nofollow">https://news.ycombinator.com/item?id=23633478</a>
Perl does have a fair few quirks but those that know it are probably content for it to stay the way it is and those who don't like it have probably moved to another language.<p>Personally, I don't like a major version of a programming language making major breaking changes because upgrading a programming language is not at all like upgrading an app.<p>Would it be so bad of them just to keep Perl as it is and imagine the 'new shiny' and give that a new name - maybe Porl or something?
I am honestly disappointed, I think Raku is a much nicer language than Perl 5 or 7<p>And I really wish, if those working on Perl 5 would have switched to Raku, but sadly i think CPAN for Perl 5/7, have a lot more activity than the equivalent at Raku<p>Most new and modern languages are Compiled, Functional or targeting the JVM or .Net frameworks<p>Raku is I think the last and only modern scripting language , it could have used the helping hand of the Perl 5/7 community
Expressiveness +
Extensibility +
Stability<p>Sounds like excellent values for a programming language.<p>I'm interested to hear what the top three values for Perl 7 are?<p>Exciting times for Perl!
Love to see the Perl team discussing these issues in such a thoughtful way. Over the years I have learned to value stability and backwards compatibility, through hard lessons (which were often quite expensive to my employer). But no one value is good or bad, per se, rather they should be selected carefully: and that is the point I took away from this article.