
Perl 7 is going to be Perl 5.32, mostly - datanut
https://www.perl.com/article/announcing-perl-7/
======
py_or_dy
I've been a perl zealot since 2005. I didn't even know "python" existed until
around 2008 when I found a script file with a ".py" file ending in a fresh
ubuntu install. I started going to perl conferences sometime after 2010 when
someone on irc informed be about them. I learned so much in those conferences,
mainly about the alternatives to cgi and the modern OOP "framework" named
"moose". I thought I was in heaven.

I landed my first devops position around the 2010 era as well and being the
only one on the team that really knew how to "program", I spammed out tons of
perl scripts and web apps. A few years later one of the newer employees on the
customer support team started spouting off about "python" and how it was so
easy to learn. He was always blabbing about terms I'd never heard of like
"generators", "list comprehensions", "decorators", etc. I looked them up and
learned they were just abstract constructs with fancy names that are supported
in most any language. So I just figured he was some idiot that didn't really
know anything. Otherwise, why would you be blabbing about abstract constructs?
He quickly landed a job at google and I left and started freelancing only
picking up perl jobs. Because perl was "dying" and this being after 2012,
there were several companies with large perl bases that couldn't find local
employees so were forced to allow remote workers.

This is where stuff started going wrong. I went through many jobs/gigs my
first couple of years. I quickly noticed that companies that had large perl
code bases were all founded pre-2005. This meant it was crap perl, in most
cases not even using CPAN but having home grown ORM's and web frameworks and a
scrict hate of javascript. So it mostly sucked and was slow going. In one case
I was literally fired after a couple of months from this one company that
specialized in phone billing accounting software (all perl powered) because I
was "too slow". The owner told me he should have never hired someone with less
than fifteen years experience with perl and bid me farewell. I almost busted
out laughing as for the entire two months I was only doing javascript front
end work since the other perl guys there hate javascript. Even the owner of
the company had no clue how his own software worked. This was a theme that
repeated it self else where as well.

Fast forward a few more years and I had landed a good remote job, still in
perl but offered more freedom in the dev cycle. I got good with react and
vue.js as it greatly speed up the dev time for all the heavy interactive apps
I was tasked with. But I continued to struggle against others in the perl
community. I can understand how a 50 year old perl dev (the typical age) would
hate javascript and instead put as much code in the back end using all kinds
of horrid html templates and never ending form post/refresh/repopulate
cycles... I can see the "why should I learn javascript if i know perl"
ideology, but what blew me away is a constant "why should I learn SQL if I
know perl" ideology. Yes I'm serious. In so many other cases devs were fine
with just doing "select *" on tons of tables and stuffing all that in a
hash/dictionary of column name matching keys. Databases were big, scripts and
page load times would grow to minutes or even hours. Sometimes exhausting the
machine's ram and crashing everything. Everyone was fine with it, management
just acted like it's how things work. Meanwhile as a co-worker, I'm left
digging through pages of perl code that could have just been a single SQL
query trying to figure out why some numbers are wrong in an invoice report. It
was a continual issue.

Another issue is just the bit rot of cpan. The ORM and drivers for both
postgresql and sqlite don't even support most of the features added in those
systems since 2014. So even though postgresql is the most advanced DB out
there, you are stuck with no ability to use any of the fancy native array or
json types or even the "natural" join syntax (and many other things), neither
good support for foreign keys in sqlite either.

I've thrown my hands up and jumped ship. It's sad too. I liked many in the
community and like Larry Wall as well and have had dinner with him on several
occasions. But I can't keep my sanity and stay with perl. I can read perl
fine, it is not the notorious "write only" language that many troll it to be.
But the issue is the community and those using perl daily are fine with being
stuck in 1995. Larry Wall stopped adding features to perl in 2002 (?) and
moved to perl 6 which.... well how do you even describe that? The point is,
perl has been the same since 2002, mean while python has had continual
development and features added every year since then. I'm just done.

~~~
Lazare
I feel you. I'm currently at a startup that, somewhat by accident, ended up
writing their backend in PHP.

Modern PHP is actually fine; it's largely avoided the issues perl has;
adoption of the latest versions is quite high, and it's...fine. Not the best,
not the worst, broadly comparable to other languages, and a far, far, far cry
from what most people may think of when they hear "PHP". My last job used
Node, the one before that used Python; I have personal preferences, but at the
end of the day they're just tools, it's all fine. The "PHP: a fractal of bad
design" blog post actually made a big impact on the community, and shocking
number of the issues listed there have been solved, with rapid active progress
ongoing. (Yes, I know, it still has issues, and people still hate it. No need
to comment to let me know.)

And yet...

...there's a big chunk of the PHP community that just really isn't on board
with any of this. Every time the core devs release a new language feature,
vocal critics complain about how the language is becoming more "enterprisey"
or "like Java". Even on the core dev team, when they vote about fixing some
crazy broken feature of the language from the bad old days, a vocal minority
is always against it. The language (thankfully) has _not_ stayed still since
2002, but people are trying.

And of course, when we advertise to hire devs, if we say we're looking for
"PHP devs", we end up flooded with applications from people who basically know
how to install and configure plugins for PHP based CMSes, or from "senior
devs" who have been hacking together procedural PHP scripts for 20+ years and
have zero knowledge of software engineering principles, unit testing, etc.
We've ended up hiring python devs to work on a php code base, not because no
php devs are out there, but just because the community is so....weird. There
are good engineers who happen to sometimes use PHP, but they rarely (if ever)
identify as "PHP devs".

I dislike the JS ecosystem and it's constant churn and cult of the new, but
sometimes you run across the reverse problem too.

~~~
adolfojp
I heard the "PHP is becoming like Java" argument in 2005 when PHP 5 came out.
I'm surprised to hear it's still a thing.

Funny enough I heard the same thing about JavaScript about 5 years ago when
ES6 came out.

~~~
Lazare
> I'm surprised to hear it's still a thing.

Ha, if anything I think it's intensified. A current focus is on adding support
for annotations (aka attributes from C#), which will be strictly opt-in and
replace an ugly pattern currently widely used in PHP land of using docblocks
to store them and then parsing them out at run time. "Hey, people keep storing
these things in comments, lots of other languages have them as a real feature,
let's do the same and make things saner and more efficient."

Simple right? But no, it's actually been quite controversial, and by no means
_just_ due to bikeshedding about syntax. Here's a selection of quotes (all
highly upvoted) from a recent announcement on the PHP subreddit announcing
that the feature has been accepted for PHP 8.0 and linking to a detailed
document explaining the use case in painful detail:

"What problem is this trying to solve? I don’t think I’m a fan." "Not sure if
I'm a fan. [...] IMO it got way out of hand in Java." "How about no? What does
it solve that you can not already program with PHP. If other languages are any
indication, its one of those changes that WILL get misused from here to high
end." "yeah no thx"

------
sumanthvepa
I was part of a team that wrote significant parts of Amazon's payment
processing systems in Perl in the late 90s. I really loved the language. It's
object system was so flexible and powerful. Once you understood how write
idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

~~~
jes5199
huh. I spent a couple years writing perl professionally, I guess that was
around 2006, and I couldn't agree less. Its object system is so bizarre
compared to any other language - it's like it doesn't really have an object
system, it has parts of a system that you can try to assemble, but no matter
what you do you end up with something weird.

And on top of that, the sigils, refs, and `wantarray` systems means that
figuring out what syntax you need to invoke something correctly is confusing
mental overhead that you have to keep in mind for _every function call_

Basically the things I learned in perl were the _least_ transferrable concepts
of any programming language I've ever worked with. You learn Haskell, or
Forth, or Lisp and you learn insights and patterns that you can use in any
language. You learn perl, and you've learned nothing but Larry Wall.

~~~
staycoolboy
Perl was my first encounter with regular expressions. To this day, no language
I've used does it better and cleaner. This includes Python, Boost/C++, Java,
JavaScript, LISP, Go and Rust.

~~~
aduitsis
Favorite syntactic sugar feature: the /x modifier which makes the regex ignore
spaces and comments, meaning you can break your regex into multiple lines and
comment them.

~~~
lizmat
FWIW, this is the default in Raku regular expressions.

~~~
aduitsis
Oh, thank you, didn't know that!

------
banana_giraffe
They last line of the article summarizes it well:

> Perl 7 is v5.32 with different settings. Your code should work if it’s not a
> mess. Expect a user release within a year.

Are there actually people that are still deploying new things in Perl? The
only times I see it is for legacy stuff, and then only because the script is
too much of a hassle to be rewritten.

~~~
smaili
IIRC Craigslist was written in Perl but that's the only high traffic site that
comes to mind.

~~~
Twirrim
The Amazon retail site is written in perl (at least the presentation layer
still is, you can find mason references still in the HTML source if you go
looking, don't know how much else behind it is in perl).

[https://metacpan.org/pod/Mason](https://metacpan.org/pod/Mason) (if you're
not familiar with Mason)

~~~
autarch
Actually, that's Mason 2. Amazon use(s|d) the OG Mason -
[https://metacpan.org/release/HTML-Mason](https://metacpan.org/release/HTML-
Mason)

------
cafard
I have used Perl since the Perl 4 days.

One can write bad Perl, and I've written a lot.

One can write good Perl, and I've written some. It has saved me and others
quite a lot of time on assorted projects.

These days I tend to use Python where once I'd have used Perl. This is mostly
because I find that the young are far more likely to know Python than to know
Perl. I will be retiring one of these days, after all.

~~~
hyperbovine
I don't think it's necessarily generational. Perl and Python differ in a key
regard: Perl went all in on TIMTOWTDI, whereas Python went in the complete
opposite direction: enforced whitespace, minimal syntax, strong use of
conventions and idioms. (When was the last time you heard somebody inquiring
about the Perl-ic way to write something?) As a result, a lot of Perl code is
an unreadable mess, and many Python programs are intelligible even to non-
programmers. It's hard to overstate what a win this is for Python.

~~~
swimfar
TIMTOWTDI="There is more than one way to do it"

------
Ovid
As a short summary about Perl 7:

If your Perl is old-school, that's OK. Use Perl 5 and we'll keeping supporting
you.

If you your Perl isn't old-school, use Perl 7 and get new features.

If you're not sure, ask us and we'll hold your hand to help you understand.

We're here to make sure you're OK.

~~~
aduitsis
Any chance Cor makes it into Perl 7?

~~~
lizmat
I understand that to be the plan.

------
CJefferson
Once this is out, I'll be interested in any well written guides or books, it
has always felt like "the one that got away" to me.

Back in 2002 I had to choose between learning between Python and Perl for a
project, but "everybody knew" Perl 5 was soon going to be replaced by a new
shiny different Perl 6, so I chose Python.

It will be interesting to see where Perl can live and gain new users nowadays.
Python has so much become the "default scripting language", and has so many
bindings and libraries.

~~~
nchelluri
I think you can learn most/all of Perl 5.32 with
[http://modernperlbooks.com/books/modern_perl_2016/](http://modernperlbooks.com/books/modern_perl_2016/)
, and it appears this is, initially, going to be 5.32 with some saner
defaults. So you could really start now, given that.

> This beloved guide is now completely updated for Perl 5.22.

I've been working with Perl since about 5.20 and am on 5.31 or 5.32 and
haven't noticed many breaking changes FWIW.

~~~
chromatic
The 2016 edition covers most of what's in 5.32; if I were to do an update for
Perl 5.32, I'd include postfix dereferencing and the built-in function
signature mechanisms now that they're very stable and supported.

------
jwr
Much as people complain about Perl, it is the language which I use when I want
to have something which will run 10-20 years from now.

I recently wrote a consistency checker for file archives (so that I know when
bitrot sets in) in Perl, precisely because I want it to be usable for a _long_
time ([https://github.com/jwr/ccheck](https://github.com/jwr/ccheck)).

Very happy to see a path forward for Perl 5.32.

~~~
latk
Interesting, I've been moving _away_ from Perl and Python and towards Rust
precisely because I'm afraid of bitrot. Perl the language is stable as fuck
and takes back-compat extremely seriously. The problem for me was the library
ecosystem: Cpan makes it tedious to pin/vendor dependencies, and installs
dependencies globally by default.

~~~
daotoad
You might want to look at Carton and cpanfiles as a way of managing
dependencies. You can also get really ancient stuff off BackPAN, should your
dependencies disappear from CPAN proper.

[https://metacpan.org/pod/Carton#Tracking-the-
dependencies](https://metacpan.org/pod/Carton#Tracking-the-dependencies)

[http://backpan.perl.org/authors/id/](http://backpan.perl.org/authors/id/)

~~~
latk
Yup, Perl7 + Carton looks like a good combo for stable programs that don't
have to be distributed publicly. I just wish cpanm and Carton were Core :D

------
Scarblac
Perl has these tiny neat features that I still miss in other languages. Like
unless (opposite of if), and postfix syntax.

    
    
        print "It worked!\n" unless $error;
        print "Item: $_\n" foreach @items;

~~~
dyingkneepad
I hate unless! It always makes me stop and think a few times, causing double
or even triple negatives in my brain. What's wrong with something like "print
this if not $error"?

Maybe that's because I'm not a native English speaker?

~~~
sergeykish
I am not native English speaker but I like it in ruby, helps with double not:

    
    
        if not not_implemented
        unless not_implemented

------
ashton314
My very first program was:

    
    
        perl -e 'print int rand(10);'
    

Good times. Good times. :)

I wrote a lot of Perl. I even wrote a small LISP interpreter entirely in Perl!
These days I write more Racket and Elixir, but there's still a soft spot in my
heart for Perl. I hope this will breath some fresh life into the language. I
think it has a lot of interesting ideas about language design that new
languages would do well to copy.

Perl is (in)famous for all the shortcuts possible in the language. While this
does steepen the learning curve, I think there are some valuable ideas worth
exploring. The implicit topic variable (`$_`) is _super_ nice when throwing
together a little script. The semantics are well laid-out in its
documentation. I think an improvement would be to somehow make it more clear
directly in the language itself where the topic variable is used. Maybe that's
what I'll end up looking at in some research. :)

Lots of languages, I feel, optimize for readability for beginners. (I'm
thinking about Python and Go here.) Perl is optimized for people familiar with
the language. I think that can be a good thing, if done right. What do you
guys think?

------
nchelluri
> PHP went directly from 5 to 7, and isn’t it time to steal something from
> that community?

:D

~~~
anon776
There was a php6... we just do not talk about it. There is a perl 6 also.

~~~
dragonwriter
There was a perl 6, but it is no longer perl, though it's still 6.

------
richard_todd
I love perl, so I’ll definitely spend some time tonight trying to find out
more about the plans. From just this article, it’s hard to see how this is
different than just making ‘use v5.34;’ flip some switches. That’s just
business as usual in modern perl, even if it changed more things than normal.
Still, if bumping the major version gets people to take another look at it, it
will be a good thing. And maybe there are bigger plans post-7.0 and this is
just to ease the initial move.

~~~
haolez
They are making some space for (controlled) breaking changes. It also sends a
message that Perl has a clear path going forward. I'll consider it for my next
projects, especially the automation ones.

------
h2odragon
Great. Perl is not my favorite language, but the things its good at and the
body of nifty code out there deserve more recognition than they get. Hopefully
this will remove some of the discouragements to curiosity that have kept
people from looking harder at perl to see if it fits their problems or their
mind better than other tools.

------
eruci
I write perl professionally as of June 2020 (and I have been writing software
in Perl since 1999). Never felt the need to use Python, or any other language
for anything I do.

People who use my (mostly) Perl based software on AWS and GCP Marketplaces
today are somewhat surprised and/or even taken aback when they find out it is
written in Perl. So, I try not to mention that.

------
Upvoter33
There used to be a big Python/Perl debate. I'm not sure I could have predicted
how well that would turn out for Python, and how poorly for Perl. Readability
and ease of use matters?

~~~
QuesnayJr
I think it was really Perl 6 that killed it. Perl had a significant lead over
Python, and the Perl 6 announcement just sucked the life out of it.

~~~
Scarblac
It wasn't the language, it was Numpy. Everything that is built on top of Numpy
is what made Python so popular.

And I guess Perl also never had its Django (or Rails).

~~~
singingfish
> And I guess Perl also never had its Django (or Rails).

It’s got two of them - Catalyst (older still works fine) and Mojo - newer and
shinier.

I think python is a better fit for mathematical work. I like to say that
python helps you think more like the computer does, and that perl helps the
computer think more like you.

~~~
cutler
Catalyst was no match for Rails. Mojolicious could have been had Miyagawa's
PSGI/Plack appeared on the scene half a decade earlier.

~~~
singingfish
rails as far as I understand is opinionated and optimised for CRUD / database
type applications. Catalyst is much more agnostic about the model you use. It
provides the flexibility and a way of structuring the code and providing debug
tooling that makes structuring a decent size app well reasonably easy to do.

~~~
cutler
Catalyst was painful to work with in my experience. Just getting it setup was
an achievement. Subroutine signatures as routes is an ugly hack.

~~~
singingfish
I like catalyst,s dispatcher. And some of the pain of installing catalyst in
the early days resulted in huge improvements to the change toolchain.

~~~
cutler
I honestly think the Perl community's attachment to Catalyst contributed to
Perl5's demise. Mojolicious was a much better bet for the future of Perl.

~~~
singingfish
I've only done a little bit of mojolicious, but it's quite nice. The
Mojo::UserAgent / Mojo::Dom tools are certainly great for writing web
scrapers.

------
oarla
I worked on Perl for a while, liked it. Back in 2008/9, the only option for
Perl on Windows was Activestate Perl, whose community version was missing lot
of features that would have made it much less painful(I am thinking of PPM
particularly). That was one of the biggest gripes I had with Perl. We moved
everything to Python as soon as we could get comfortable with it and haven't
looked back since.

Regarding Perl's one liners, I feel they are what makes Perl very useful, but
my preference is AWK over Perl for that.

~~~
kbenson
I actually found ActiveState and ppm to be fairly useful when I was doing
cross system Perl around the same time. You could get the same ActiveState
versions for Linux and Windows and have a more consistent environment. In the
few cases ppm didn't have what I needed, I would just use a CPAN client.
Pretty sure I even got the CPAN client compiling some libs for windows (which
took a bit of work, but wasn't impossible).

I even used that setup to package a couple Perl scripts with all their modules
into PAR archive executables, circa 2011 I think.

> Regarding Perl's one liners, I feel they are what makes Perl very useful,
> but my preference is AWK over Perl for that.

I love the ability to pull in a CPAN module or two to really kick up a one-
liner a notch without making it too long. Also, I like creating an alias to
perl that loads up a few useful libs and the main project lib and putting it
in the project path so I can use a one liner like a REPL and run small
queries, reports, or even do complex DB queries/updates with it using
DBIx::Class and all the helper methods I've created for this project's schema.

------
fmakunbound
According to the Modern Perl author, Five things Perl (Still) Gets Right:

* Compatibility

* Quality

* Usability

* Scalability

* Availability

[https://pragprog.com/titles/swperl/](https://pragprog.com/titles/swperl/)

~~~
timwaagh
Mostly the last one. It's included by default with most linuxes and cygwin. So
even if your boss hates you and doesn't let you install anything you can still
write scripts.

------
ksaj
Are they still renaming Perl 6? I think it is a tad confusing to have 5 and 7
being so similar, and the 6 in between so radically different. I can't be the
only one.

~~~
filmor
Perl 6 was renamed to Raku in October 2019.

~~~
ksaj
Ah, I am glad the name change happened. I got side tracked before it came to a
conclusion. I'm guessing if it didn't happen then, it surely would have to be
changed now because of this new version, which looks like far less of a fork
in the road.

I know some people aren't fans of Perl5, but it's what I learned and I wasn't
all that excited to have to toss everything I knew (and my reference books)
just because of a new version number. If Perl6 turns out to be complementary
as people were saying/hoping, maybe Perl7 is where we get to see the
interplay.

~~~
lizmat
Perl 6 has been renamed to Raku ([https://raku.org](https://raku.org) using
the #rakulang tag on social media). You can run Perl inside of it if you want
to, with the Inline::Perl5 module. Check out the Rakudo Weekly News
[https://rakudoweekly.blog](https://rakudoweekly.blog) if you want to stay up-
to-date!

~~~
ksaj
I'm surprised to see .pm6 extension still being used, at least on the rakudo
documentation page. Do those contain Raku code, or Perl?

~~~
lizmat
These would contain Raku code. But as with Perl, the core developers value
backward compatibility much. Since many versions of Raku in use do _not_ know
of the new .rakumod extension yet, the old extension is used for many modules
still.

This is probably going to change in the next language revision of Raku. See
[https://github.com/Raku/problem-
solving/blob/master/solution...](https://github.com/Raku/problem-
solving/blob/master/solutions/language/Path-to-Raku.md#extensions) for the
nitty gritty.

------
Ovid
Just to be clear to everyone: this doesn't break anything. If you continue to
use Perl version 5, you're fine. If you want to upgrade your major version of
Perl, then of course you need to know what that means.

~~~
briandfoy
To clarify this: if v5.32 can run your code, you should be safe. There have
been various small changes in Perl 5 that might not handle something you wrote
in 1995.

------
peterwwillis
This is possibly a stupid comment, but I'd love a modern language whose
expected lifetime is 100 years. A language whose specification details how it
can be run for 100 years on changing hardware + operating systems, and is
built with the least amount of, and easiest to perform, maintenance in mind.

Those languages kind of exist, but not expressly written as such. C will
outlive us all.

------
EricRiese
You guys are just now getting to Perl 7? I'm already on Perl 11.
[http://perl11.org/](http://perl11.org/)

~~~
lizmat
The Perl 11 initiative was started by some individuals in the Perl community,
but it never gained much traction outside of the group around the ones that
started it. It has been dormant for at least 8 years now.

------
OakNinja
Developers in their forties wrote Perl. Developers in their thirties replaced
Perl. Developers in their twenties say “What’s Perl?”

~~~
cutler
Yes and developers in their 50s retired in their mid-30s after making fortunes
writing Perl.

~~~
davorg
I wish :-)

------
p1necone
I'm trying to work this out but not having much luck - Perl 6 was a "lets make
a bunch of breaking changes and modernize Perl a bit", and now that's branched
off as a new language called Raku.

Now there's Perl 7, which is sort of the same idea as Perl 6 was, but less
radical with the changes? Are the same people working on both? Is Larry
involved with both?

~~~
triangleman
I believe it's not radical at all compared to the Perl 6 idea. It's basically
"strict Perl 5" if I'm reading it right.

If Larry had said from the start "Let's make a new language and call it Raku"
we would have had Perl 6 long ago, it would have been called Perl Enterprise
Edition in the business world, and you'd never have heard of Python or PHP
because everyone would be using Perl. Oh well, better late than never.

------
gkfasdfasdf
I still use Perl every now and again for powerful one-liners and I'm really
glad it's around. Here is a bash function I use which takes args and merges
and deduplicates PATH-like expressions:

    
    
      merge-args () 
      { 
        perl -e 'print join ":", grep {!$h{$_}++} split ":", join ":", @ARGV' "$@"
      }
    

And I use as follows:

    
    
      export PATH="$(merge-args "${SCRIPT_DIR}"/clang-tidy-ex /usr/local/opt/llvm/bin "${INSTALL_DIR}"/{,samples/}bin "${PATH}")"
    
      ASAN_OPTIONS="$(merge-args "${ASAN_OPTIONS}" detect_leaks=1 check_initialization_order=1 detect_stack_use_after_return=1 strict_init_order=1 strict_string_checks=1 detect_odr_violation=0)"
    

I know there are other ways of doing this in other languages and even in bash
itself, but to me this is simple and elegant.

~~~
Spivak
A pure bash alternative for comparison.

    
    
        merge-args() {
            local res
            for i; do
                case ":${res}:" in
                    *:"$i":*)
                        ;;
                    *)
                        res=${res+$res:}$i
                esac
            done
            echo $res
        }

~~~
gkfasdfasdf
That is pretty neat, I did not know that 'for i' on it's own could iterate the
args like that.

------
henearkr
I had hope there would be a merging (with some compatibility layers and
wrapper binaries) allowing to use Raku the same way Perl 5 was used (should
not have been _that_ hard, just adding familiar options and special
variables)... Now I'm seeing this goes in a total different direction.

~~~
lizmat
Perhaps. Meanwhile, the most recent release of the Inline::Perl5 module of
Raku allows one to have code blocks written in Perl inside Raku code, and
vice-versa. And of course be able to use any CPAN module from Raku:
[https://modules.raku.org/dist/Inline::Perl5:cpan:NINE](https://modules.raku.org/dist/Inline::Perl5:cpan:NINE)

~~~
henearkr
Nice! I didn't know. But it still does not bring back the classic usage in
Perl 5 style, that made intensive use of runtime options as shorthands for
looping on all lines of a file etc.

------
rurban
To be on topic:

Perl7 is basically the idea to modernize saner settings by default. And
breaking backcompat where it hurts. But it's far off a modern perl, like cperl
is. They failed to fix the worst historical design mistakes. The hashes, the
OO, types, @_, attrs before signatures (which was a major breaking change, but
they excused themselves by claiming it was experimental), and many more.

[https://github.com/perl11/cperl/issues/414](https://github.com/perl11/cperl/issues/414)

Instead they are breaking indirect method calls. Thanksfully this will be not
POSIX, so nobody will use it.

------
edw
This article touches on something that I really enjoyed about (the early days)
of Perl 5, and I think it may body well for the future of the language.

You could write Perl 5 like it was just a better Perl 4. All of the craziness
with modules and references was hidden to you if you wanted to write a Perl
4-esque script that needed to talk to a database or do something else that you
could find a module in for in CPAN.

The people would _wrote_ those modules, God help them, I don't know how they
managed to write the executable line noise that was in the source, but I
didn't care. I could get my job done with a few simple `use` statements.

------
tolger
This is great news! I was really excited about Perl 6, until I realized it was
a different language, and it never quite jelled into a usable thing. So I kept
using Perl 5. I write mostly modern Perl code, so this is exactly what I
wanted.

I learned Perl back in the late 90's when it was the best way to do web
programming. As a C programmer, it was a breath of fresh air. It was a higher-
level C for me and I used it for prototyping all kinds of things before
writing the production level C code. Nowadays, I still use it for system
maintenance and prototyping. It's a great language and very powerful tool.

~~~
lizmat
No idea when it was the last time you tried jelling. But Raku is very much a
usable thing nowadays and is used in production:
[https://raku.org](https://raku.org)

~~~
tolger
That's good to know. I will definitely check it out. Thanks!

------
ojosilva
The proposed defaults are a good idea, and I hope some or most of 5.32 long
standing experimental features become core features (or just go away
entirely).

But I'm afraid that the badly needed core C code refactoring and restructuring
is being left out, and that will make it very hard to introduce new features
into the language.

I also had this secret hope that Perl 7 would be a tidier, simplified Perl 5
with little or no relation to Perl 6. Less confusing syntax would go in sync
with the refactoring of the core to create a smaller language that could
perform better and be easier for beginners to learn.

~~~
redis_mlc
> I also had this secret hope that Perl 7 would be a tidier, simplified Perl 5
> with little or no relation to Perl 6.

That's what the article says.

> could perform better

Perl's performance is not an issue.

------
elchin
What project, if you were starting now from the scratch, would you use Perl
for?

~~~
superkuh
Any project that runs on a computer (not a microcontroller) that doesn't need
a hardware accelerated multimedia. But even if the later you can always use
sdl2.

My last three perl projects (not counting throwaway minor scripts): The
control interface of a galvanic vestibular stimulator for VR motion sickness.
A GUI for doing the required quirky edits to text files for text to speech
smoothness. A comment system for a static website.

------
mrits
I've had to write some Perl in my latest project. Coming back to a language 20
years later at 37 years old was very interesting. I'm not a fan of the
language but I can see why people like it.

The largest issue I've had is that even though the ecosystem gives you the
ability to write code resembling best practices, I don't see a lot of Perl
programmers that do it. Coming onto a project it didn't make sense to catch a
whole team up on 20 years of best practices. So I went about writing code that
would never be accepted on most of my other teams.

------
senthilnayagam
Perl 6 with parrot VM was expecting release in 2004, we had some portion of
our code in perl. other portions were in php4. chose ruby due to rails
announcement in 2004.

will wait for actual release will try on some pet project

~~~
lizmat
Perl 6 actually got released in December 2015. Meanwhile it got renamed to
Raku ([https://raku.org](https://raku.org) using the #rakulang tag on social
media). You don't have to wait anymore to be able to use it on a pet, or even
a business project. Check out the Rakudo Weekly News if you want to stay up-
to-date: [https://rakudoweekly.blog](https://rakudoweekly.blog)

------
pflanze
Maybe someone here is the right person interested in this: I've been working
on making Perl more suitable for functional programming[1]. This project still
needs a lot of manpower to become something good. I need people to work with
me on this, I won't continue alone. Please give me feedback about where I
should be going with it, or tell me if you're interested in joining the
effort.

[1]
[https://metacpan.org/pod/FunctionalPerl](https://metacpan.org/pod/FunctionalPerl)

------
jVinc
I'm sorry if this offends. But a complete laypersons* perspective from someone
who hasn't been keeping up on the current perl ecosystem is this: perl6 failed
to the degree that perl 5 became perl 7, while all the perl programmers
switched to ruby or python. Am I wrong?

*ok, not completely layperson, I used perl a lot a decade ago an have spent a week playing with raku at one point, but nothing in my professional life even has a slight smell of perl anymore, which is strange seeing as 90% of our company codebase was perl 15 years ago.

~~~
lizmat
Perl 6 / Raku _did_ achieve its goal of a programming language that kept all
the good parts of Perl, and remove it warts, making it ready to become the 100
year programming language.

In my opinion, the failure is in the timing of the process, and keeping the
Perl community involved in the process.

------
iso1631
Wow, I haven't written any perl since

 _checks_

5.27 pm today.

------
Animats
Thus the embarrassment of Perl 6 is erased from history.

~~~
lizmat
Perl 6 may be erased. But the Raku Programming Language
([https://raku.org](https://raku.org), using the #rakulang tag on social
media) rose from its ashes.

------
rad_gruchalski
Perl 5 was great. Written so many things in it. Looking forward to 7. Maybe
time to start doing new things in perl?

------
jasonhansel
Why does this happen so often to certain language version numbers? ECMAScript
4, PHP 6, and now Perl 6.

~~~
peteretep
Second system syndrome

------
qalmakka
Perl is the swiss army knife of the shell. Works the same everywhere, it has
always been reliable and superuseful for simple to medium scripts. It's the
glue that keeps a lot of stuff together, and I'm happy it got back to its
tracks after the v6 faux pas.

------
rplnt
> > use utf8;

> there’s still much to be done to make Unicode the default

Why's that? If that's something someone with zero Perl experience can easily
understand. Isn't this only about the source code? Or does this mean all
strings are unicode?

~~~
moonchild
This[1] explains it. Essentially, to support unicode probably, you have to do
extra work in your own code. (How do you handle invalid unicode? Should regex
character classes match the unicode versions, or just the ascii versions?
etc.) Additionally, certain builtin functions don't already support unicode,
and modifying them to do that would be a breaking change. For more info, see
the py2->py3 unicode change, and how much of a mess that caused.

1\.
[https://stackoverflow.com/questions/6162484#6163129](https://stackoverflow.com/questions/6162484#6163129)

------
newshhh
People just keep wasting their precious lives on archaic stuff that has no
future. Perl is dead. If these smart minds want to contribute to humanity,
they should abandon this sunken ship and move to something more meaningful.

~~~
yellowapple
> Perl is dead.

Seems like DuckDuckGo didn't get the memo.

------
sabujp
Perl5 was the first language in which I actually did some substantial
projects. It was also heavily used in scientific computing (esp. genetics)
until python came along.

------
srathi
Perl readability is rivaled only by c++ template code!

------
adenozine
What is there to gain in calling it Perl 7? It seems needlessly disruptive,
rather than just calling it 5.34 or whatever is next.

~~~
tux1968
It's reclaiming the Perl name since Perl 6 has abandoned its connection to
Perl and is claiming to be a completely separate unconnected language.

This is the logical conclusion to this divergence and will mean that going
forward people wont think Perl 6 is the newest version of Perl. That problem
would still exist if you leave Perl at 5.35 since search engines are still
happily returning pages for Perl 6 even though it's no longer a thing.

------
fizixer
Need a comprehensive, up-to-date, yet brief, status of what happened to Perl 6
and where it stands in today's s/w tech.

~~~
Floegipoky
Perl 6 is basically a totally different language than any other Perl, and it
took a very long time to go from announcement (2000) to release (2015). It was
renamed to Raku last year.

~~~
cutler
String parsing - Perl5's forte - is still dog slow with Perl6/Raku and year
after year we hear that will change in the future. Don't hold your breath.

~~~
daotoad
Raku's big strengths lie, IMO, in the command line scripting capabilities (the
MAIN function), parsing with grammars and powerful new regex syntax, and as a
glue language. It's relatively easy to bind to external libraries and work
with them.

Look at how easily raku binds to a python charting module in this article:
[https://www.perl.com/article/plotting-with-
perl-6/](https://www.perl.com/article/plotting-with-perl-6/)

~~~
cutler
But if it's slow at really basic stuff users will ignore it, surely?

~~~
lizmat
Slow is in the eye of the beholder. Sure, for some applications, Perl blows
Raku out of the water. Add in some Moose, and the situation is not so
different. YMMV.

~~~
cutler
On my 4-core i7 Macbook Pro parsing a 20Mb log file with a regex takes 9.4
times longer with Raku than Perl5. That's unacceptable. Adding Moose to Perl5
reduces the differential to 7.1 which is still huge.

~~~
lizmat
Do you have a gist of your code and a representative sample of the log file
you're parsing?

~~~
cutler
It's a one-liner:

    
    
        for 'logs1.txt'.IO.lines -> $_ { .say if $_ ~~ /<<\w ** 15>>/; }

------
classics2
Glad to hear it. Perl 6 was some kind of twisted complexity pornography.

------
odc
This is fantastic news! I'm glad perl 5 is evolving again.

------
_____smurf_____
In some companies, they have huge projects written in Perl

------
qbaqbaqba
Reasonable since "perl6" issue is solved. Everyone may move forward.

------
markstos
Perl is alive!

------
frjalex
After a million years, it is finally out!

------
rodrigo975
Finally!

------
r00fus
tl;dr - Perl 7.0 is going to be v5.32 but with different, saner, more modern
defaults.

Perl was great 20 years ago for basic scripts. Where is it still used today
who hasn't transitioned to Python/etc?

~~~
toast0
Perl continues to be great for basic scripts. Why change and throw away 20
years of experience?

The only thing I've noticed that's lacking is decent protobuf support.

~~~
radiator
Some people would consider that a good thing.

~~~
toast0
I assume you're saying it's a good thing there's no reasonable protobuf
support? The problem is I have access to data I'd like to manipulate, but it's
in protobuf, so my options are:

a) somehow convince Google to let me access Nest data through a proper API

b) get a different thermostat

c) magically get the perl protobuf libraries to actually work

d) write just enough protobuf parsing (and possibly generating) to read my
data, and curse

e) use another language to parse the data (ugh)

(I guess you could like to throw out 20 years of experience)

------
billman
sub foolOnce() { return raku(); }

sub foolTwice() { return perl5(); }

~~~
cutler
You left-out unrolling @ :).

------
polynomial
Amazing. I literally first installed this on my laptop over 10 years ago.
(Using Parrot)

~~~
lizmat
If it was using Parrot, you probably installed Perl 6 (at the time, now known
as Raku).

~~~
polynomial
Ah you're right, it was 6. Amazing to see Perl still going after all this
time!

------
foobar_
This is just bad maintenance. Just pick all the stuff people are complaining
about and fix it!

1\. Improve threads

2\. Improve C API support

3\. Give local::lib, cpanm by default ... multiple perl versions by default

4\. Give direct support for coroutines / async await

5\. Mark experimental features as non-experimental (attributes, signatures)

6\. Pick an OO system, package system

7\. Make switch cool again

8\. Get more core modules or remove some. Give more visibility to cool perl
modules. like PDL or something.

9\. Improve GUI toolkit, Web Deployment and Web Assembly support

10\. Improve look and feel of community sites

Heck break some backwards compatibility with Perl4, get rid of format.

~~~
noisy_boy
One more: add a proper exception handling setup.

~~~
foobar_
Yeah that too! People keep saying perl is a bad language or something and the
other languages can't even get implementing closures right.

I've always liked the references syntax, probably the most complained about
feature. Its just pointer thinking. You could probably collapse
`$array[$x]->{"foo"}->[0]` to `$array[$x]{"foo"}[0]` and save some keystrokes.

~~~
mfontani
> probably collapse $array[$x]->{foo}->[0] to $array[$x]{foo}[0] ...

Yup, one's been able to collapse exactly like that for more than twenty years.

[https://metacpan.org/source/LWALL/perl5.002b3/pod/perlref.po...](https://metacpan.org/source/LWALL/perl5.002b3/pod/perlref.pod#L289)

That's from 5.002, from last century, and it wasn't introduced on 5.002.

Beginning from v5.20, one's also been able to use the postfix dereference
syntax, turning:

say join "\t", @{ $foo->{bar}[0]{quux} }

into:

say join "\t", $foo->{bar}[0]{quux}->@*;

Whether that's better or worse, it's debatable.

~~~
foobar_
You're right! I always preferred the explicit arrow because it reminded me of
C. Dammit now I want to write perl. I miss autovivification so much. Most
people hate the pointer syntax and call it unreadable. I think there should be
a perl tricks page that lists all these tricks.

------
bhaavan
This feels like a last ditch attempt to save a dying language.
([https://i.imgflip.com/4676mf.jpg](https://i.imgflip.com/4676mf.jpg)) I
wonder what exactly does Perl bring to the table as a language, why would one
consider choosing it over other languages.

~~~
IvyMike
Regular expressions as a first class language feature.

~~~
cutler
Ruby also has this.

~~~
earthboundkid
Ruby really is Perl done right. I can't really see any argument for Perl over
Ruby as a language.

~~~
dhosek
use strict. In Perl you can prevent something like the following from
compiling. You can't with Ruby (unless they've _finally_ addressed that).

    
    
       $foo = 2;
       if (some_test()) {
          $fooo = 3;
       }

~~~
cutler
Shouldn't that be:

    
    
        my $foo = 2;
    
    ?

~~~
dhosek
I was leaving the declaration implicit.

