
Perl7 is a fork of values - lizmat
http://blogs.perl.org/users/leon_timmermans/2020/08/perl7-is-a-fork-of-values.html
======
lmiller1990
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.

I find this post a little unsettling. It seems like even the Perl community is
unsure why they are doing this.

At least for me, Perl === Perl 5 (and probably always will). It works, and
it's ecosystem is very mature.

~~~
chomp
Something’s gotta change though. The path perl5 is on ends in dead language.
It’s not attracting young talent, the last really high profile project that
sticks out in my mind is Perl Dancer which was released in 2011, and modules
on cpan are getting dusty/losing maintainers.

I also created and maintain a large Perl stack and in my opinion, the things
that made Perl great 10-15 years ago, other languages have adopted and did
better. Now for lack of want of updating the language, it’s just languished. I
just don’t see a compelling reason to start a Perl project in 2020.

~~~
jerf
Then let it die in maturity, going down providing value to its users to the
last, and focusing on any needs its remaining users may still have. Way better
than stabbing it's user base in the back, and _still_ not attracting any new
users. Because there's no feasible way Perl can just tweak a couple things and
open up a new user base. It is what it is.

The whole "stab our existing users in the back and chase a new user base"
model has been bizarrely popular lately, but I'm not sure I've seen it work
even once.

(I exaggerate a bit with "stab", but still...)

~~~
claydavisss
> Then let it die in maturity

That can be achieved right now for anyone who is interested: download Perl5.32
and never update it. No one will ever force you to upgrade to Perl7 if you
don't want to. Why hold everyone else back when remaining in a static state
can be done in isolation?

~~~
nonbirithm
> download Perl5.32 and never update it

I think this is an interesting sentiment when contrasted with the Python 2/3
split, where most people are pushing to get projects into on 3 and warning
users of 2 they will not be getting official security patches any more. Maybe
because Perl's community is smaller they wouldn't be as hard-line on this and
release security fixes for Perl 5 if they were merited (though I don't see
Perl as a tempting target for malware authors).

It feels like that article states that some people in the Perl community want
to make the breaking changes to free themselves of legacy and gain the
advantage of accessibility from new users by doing so, being that Perl 5
desperately needs new users, but contrasts this with the fact that protecting
that legacy was both a core value of the Perl project and possibly one that
held it back for too long.

I honestly wonder where we would be if Python never made the 2/3 split and
we'd all still be using Python 2 at this point with all of its design flaws.
Surely it wouldn't die from becoming outdated, seeing other languages do the
same things better, as with Perl?

------
qalmakka
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.

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.

~~~
cwyers
I am not a Perl person, but it does sound to me like a lot of this thread is
is missing what's going on, yeah. They're not changing the language, they're
just changing the runtime to use better, more modern defaults. I don't know if
you would be able to put in "use unstrict" or something and get back the old
behavior, but any actively-maintained code is probably using most of these
newer defaults anyway.

~~~
HighPlainsDrftr
Brian D Foy wrote a pretty good post on this.
[https://www.perl.com/article/announcing-
perl-7/](https://www.perl.com/article/announcing-perl-7/)

Essentially, it is just perl 5.32 with more modern defaults. They will keep
evolving the language. Perl 5 isn't going anywhere.

------
kinow
Had a chance to work with Leon on the TestAnything protocol. Really great guy
to work with.

>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.

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.

~~~
leont
> Had a chance to work with Leon on the TestAnything protocol. Really great
> guy to work with.

Why thank you :-)

------
CydeWeys
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?

~~~
PCChris
They are talking about the next iteration of Perl 5.
[https://www.perl.com/article/announcing-
perl-7/](https://www.perl.com/article/announcing-perl-7/)

------
beefhash
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?

~~~
greggyb
/bin/sh?

I am not sure what the balance of facetious vs serious is here. The various
Unix shells have been stable for quite a while. Obviously sh is very
barebones, but zsh and bash, for example, have associative arrays and other
modern conveniences.

Outside of various shells, there are several other options that come to mind
which do not teeter on facetiousness.

So far as I know, tcl is also quite stable.

Common Lisp is perfectly usable as a scripting language and has a very stable
standard and mature libraries.

~~~
iso947
The reason I reach for Perl rather than bash is it has far more features and
far easier to manage.

I don’t bother with python as you get into a horrendous mess with pip breaking
and the v2/v3 issue.

Not every piece of code needs to serve a million people, not every piece of
code needs to be sold to google, sometimes you just need code to do a simple
occasional job and not change every couple of years.

~~~
jefftk
Python is fully on v3 now. It was a terrible transition, but it's done.

~~~
Izkata
Hahaha no. Much of our code is still v2, with no hint of a transition
happening any time soon. It's mostly in maintenance mode.

Quick edit: To sibling comment's point, we're not a tech company, so it's very
difficult to get this type of work done. It pretty much only happens on new
development (where we are using python3), but that new development doesn't
replace the old code.

~~~
scoopertrooper
Python 2 just reached end-of-life with the last-ever update arriving in
October this year. So you better get moving soon if your code isn't completely
air gapped.

[https://adtmag.com/articles/2020/01/09/python-2-end-of-
life....](https://adtmag.com/articles/2020/01/09/python-2-end-of-life.aspx)

There are current three outstanding CVEs for the latest version of Python 2.
Hopefully, they'll be patched up in the upcoming release, but good luck after
that.

[https://www.cvedetails.com/vulnerability-
list/vendor_id-1021...](https://www.cvedetails.com/vulnerability-
list/vendor_id-10210/product_id-18230/version_id-305022/Python-
Python-2.7.17.html)

------
rurban
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."

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.

~~~
tomphoolery
> Breaking back compat without any new features on the horizon to justify them
> is not only ridiculous, it's suicide.

I disagree. EmberJS is a great example of this philosophy done right. Major
releases of Ember typically have no new features, they just break backwards
compatibility in favor of more efficient ways to do things. This "sets the
stage" for features that get added in minor releases. So when Ember releases a
new major, you typically don't have to upgrade to it if you don't want the new
features. But it's released so you can measure the level of effort as well as
the impact the upgrade would have on your codebase. Contrast this with the way
Ruby on Rails releases new major versions, with one giant release every couple
years that either breaks compatibility, causes performance/cognitive issues,
or some combination of the two.

In my opinion, major versions _shouldn 't_ have new features. The way Ember
gets away with this is by sometimes releasing two versions simultaneously, a
major "X.0.0" version for upgrading apps to measure the level of effort, and a
minor "X.1.0" for new apps. Want to start a new app? Choose the first minor.
Want to upgrade your old app? Choose the major.

~~~
jlg23
I am not sure one can compare some JS framework with a language that was
already 8 years old when JS as a language appeared. By the time JS was
invented, there was already legacy perl code in production that needed to be
maintained.

~~~
tomphoolery
I don't see how that's relevant to software project management. The ways we
release software and plan out roadmaps don't really have much to do with what
language or framework the software was made in. Just because Ember is "some JS
framework" doesn't mean it has no good ideas.

~~~
richard_todd
To me it's really not about whether it's a good idea or not. What works for an
8-year-old project that has always done it that way, may not work for a
33-year-old project which has _never_ done it that way. The latest perl will
run a huge chunk of the perl 1.0 test suite unmodified. That's a long history
of backwards compatibility. This sudden change in focus and project-management
may really backfire on them.

------
gjvc
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.

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.

------
randallsquared
I wonder if Perl 8 will also be a fork of Perl 5.

------
mkoubaa
a similar argument is going on in c++ community - whether to value stability
or performance.

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.

~~~
paulryanrogers
Perhaps spreading out the breaking changes as PHP has done from 4 through 7.

~~~
dgellow
One thing specific to C++ is that the main point of discussion isn't
necessarily about the language itself, instead it is about breaking the ABI or
not moving forward. Breaking the ABI would allow for significant performance
improvements, but that would require a huge amount of libraries to be
recompiled, which is something a lot of vendors don't want and sometime cannot
because sources aren't available anymore.

~~~
im3w1l
What about something like this?
[https://devblogs.microsoft.com/oldnewthing/20040108-00/?p=41...](https://devblogs.microsoft.com/oldnewthing/20040108-00/?p=41163)

------
im3w1l
Which kind of greenfield projects would the perl community like to claim? Is
there anything it's particularly suited for?

------
jlokier
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.

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.

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.

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.

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.

But it should be easy for scripts to specify what they want.

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.

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.

------
py_or_dy
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.

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.

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???

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.

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.

Anyway, to each their own. And godspeed to the perlings out there, I just
don't see how any of this is worth it...

[0]:[https://news.ycombinator.com/item?id=23633478](https://news.ycombinator.com/item?id=23633478)

------
jarym
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.

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.

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?

~~~
evilsnoopi3
I mean they already tried that with Raku (Perl6) and it didn't gain the
adoption they wanted.

------
systems
I am honestly disappointed, I think Raku is a much nicer language than Perl 5
or 7

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

Most new and modern languages are Compiled, Functional or targeting the JVM or
.Net frameworks

Raku is I think the last and only modern scripting language , it could have
used the helping hand of the Perl 5/7 community

~~~
Icathian
Isn't Python typically considered a scripting language, and usually ranked as
at least top 3 in popularity?

~~~
systems
Yes, but the way i see it, Raku (Perl6) was a complete rewrite of Perl .. was
a radical change (rational numbers, grammar, multimethods, ...)

Python 3, is in my opinion more of an incremental and conservative change

------
nige123
Expressiveness + Extensibility + Stability

Sounds like excellent values for a programming language.

I'm interested to hear what the top three values for Perl 7 are?

Exciting times for Perl!

------
jpz
what happened to perl6? I'm confused :)

~~~
systems
They renamed it to Raku, the renamed have two benefits in minds

1\. Reintroduce Perl 6 (Raku) as a completely new language, since some thought
that being linked to Perl prevented adoption

2\. Open the road for Perl 5 to evolve and add features, many people in the
Perl 5 community thought that Perl 6 prevented Perl 5 from growing

In Summary, the sentiment was, Perl 5 and Perl 6 are two different languages
each with its own roadmap, but that the name gave the impression they are one,
and prevented both from evolving

~~~
jpz
cheers, TIL :)

------
amai
Perl7 is as important as Rocky 7 or Terminator 7.

------
dilandau
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.

------
nintendo1889
I always wondered what the trolls on slashdot posted about Tom Christiansen
when he died. The posts were all deleted.

~~~
gjm11
Huh?

Last I heard, Tom Christiansen is still alive. And I'm not sure what the
connection is, other than that he's done a lot of work with perl.

~~~
jph00
I believe he's talking about the thread when W Richard Stevens died.

~~~
gjm11
(Apologies for the very slow response.) W Richard Stevens died in 1999. HN
started in 2007. Is it possible that you're thinking of someone else?

~~~
jph00
They said slashdot, not HN.

~~~
gjm11
Ohhhh, duh, so they did. Thanks.

