It is already modern. The Perl community has boldly remained committed to compatibility over chasing the shiny and breaking shit, unlike many others (coughphpcough), which is why I chose Perl for a new project a couple years ago.

I don't WANT so-called modernization. I want my program to remain working without having to change. it

> I want my program to remain working without having to change. it

Can't you bundle the interpreter, possibly stripped down and compiled as a static binary, along with your program?

But yes, strict backward compatibility, while having many downsides, provides a lot of value, too. The trade-off is situation and project dependent, and it's good to have both kinds of platforms: ones solid as a rock and moving slowly, and ones moving fast and breaking things.

https://metacpan.org/pod/pp https://metacpan.org/pod/staticperl https://metacpan.org/pod/perlcc

But that's the worst way to deploy a program.

This will work for awhile until you stop receiving security updates and have to adapt to breaking changes to do so.

Bundling the interpreter would interfere significantly with being able to download and run from source.

I liked writing Perl a lot, but when it came to reading, let alone fixing, other people's Perl, it was always a bit of a nightmare. That's one of the main reasons I was reasonably happy to move away from it - nobody seemed to heed "Just because you can, doesn't mean you should" mantra. Sure you can write good Perl, and I always did my best in that area, but it was not the reality for most Perl programs out there. CPAN also turned to a bit of a mess at some point, and in general dependency management was non existent, really. Containers could help alleviate this pain now, to an extent. Still, it would need to seriously improve to lay any claims to being able to write modern stuff in Perl.

CPAN is great, but also horrible. There are so many packages that do the same thing, and it was often hard for me to know which to pick. Want OO? Use Moose, or Moo, or Mouse or whatever else. Then hope that the one you picked will continue to be maintained. I resisted moving to Python for a long time, but when I finally did it was a bit refreshing to have more packages built into the language so I didn't have to make so many choices on what 3rd-party libraries to install. Perl will always have a special place in my heart though.

As far as reading code goes, Perl could be particularly messy, but I've seen some very hard to read Python code as well. And Javascript... I still don't get why people want to use it server-side. But all these languages have tooling that helps make sure code is at least formatted correctly, and follows some sort of best practices. I think one of the hardest parts of reading Perl, to me, was that it wasn't always clear what package a particular function or class was imported from.

> CPAN is great, but also horrible. There are so many packages that do the same thing

IMO, that's a good thing. Imagine having only one choice at any layer in society (to make my example extreme): one type of house, one type of car, one type of computer, on type of OS, one type of file system, one type of programming language etc.

> Want OO? Use Moose, or Moo, or Mouse or whatever else.

This is true; no built-in "proper" OO has been a pain for Perl for a long time. However, I've used to love Mouse (like Moose, but a trillion times faster), and I've never had any problems with it.

There are plans to inject proper OO into Perl, though.[1]

> Then hope that the one you picked will continue to be maintained.

This is my biggest problem. I wish there was a "system" of sorts that let _groups of people_ adopt/take over a Perl module and Just Fix It (tm). Having only one person take over a module/package isn't good enough; there must be more people involved in fixing things.

One good example is Crypt::Curve25519[2] which could/should have been fixed years ago, but because the maintainer is inactive, it won't happen.

And now we're back to where we started: because things doesn't get fixed, people create their own versions of CPAN packages just for the F[ix|uck] of it.

[1] https://dev.to/ovid/bringing-modern-oo-to-perl-51ak

[2] https://metacpan.org/pod/Crypt::Curve25519

There is an adoption process for truly inactive maintainers: http://neilb.org/2013/07/24/adopt-a-module.html - you can also often get somewhere by just asking the current maintainer nicely by email. The timeliness of the process in the event of a non-repsonsive maintainer depends on luck and how much depends on the module. In the end it doesn't matter if a group or a person adopts it - someone still has to decide to do the work.

> There is an adoption process [...]

This is good, but to me it's too tedious. I can't wait a month for something to happen. The solution so far has been to fire up a Pinto server and serve "home-made-patched" versions of modules, which only benefits myself, not the community.

> [...] you can also often get somewhere by just asking the current maintainer nicely by email.

What could be more intrusive than creating a pull request or git issue? An email.

Just use Moo or none at all. Moose is to big and slow pulls too many deps for my taste, Mouse involves XS. Perl is messy if your coding is messy. Why server side? Because DBI, Mojolicious and a good glue language for business logic already written in Perl. Would I pick it for something new? Maybe simple scripts or some quick web service or web API access tool or things involving text processing.

I use almost no third-party modules and write largely what I call "PHP style" Perl, so mostly $variable = SomeFunction($someOtherVariable);

I've had no issues with reading my own code, and others are able to follow along as well.

I admit that, because of its poetry-enabling flexibility, in terms of readability and maintainability foot-shooting, Perl is like an AK-47 with a full clip and no safety.

I wonder if they got burned by Perl 6/Raku. That had tons of new features but took so long to deliver that it became a burden. Anyway, I think you're right: they have to be more proactive than just going for "feature parity with a modern language".

> I wonder if they got burned by Perl 6/Raku.

I have the same feeling. I've been programming Perl since mid 90s, and I was - as many others - hyped when Perl 6 was announced early 2000s. 20 years later, it's just different programming language in my eyes; I won't spend any time on it, because if I need Perl, Perl 5.x will do just fine.

Unfortunately, because of Perl 6/Parrot/Raku, or what the current name is, I think it made many developers get off the Perl train. There are lots of good frameworks for Perl that makes it super-easy to get something up and running really quickly;

    * Mojolicious (and its multitude of plugins, Minion etc.)
    * DBIx::Class (not pretty, but still just works)
    * Moose/Mouse (for decent OOP)
    * JSON::Validator (and friends, for mocking and validating)

The list goes on, but this is the "out of the box"-stuff for me to get up and running with something, if not just a prototype of something.

Wasn't Perl 6 itself a reaction to the fact that a lot of developers already leaving for PHP in the web space and Python in the "I need something like a shell script, but need/want a real programming language".

No. http://strangelyconsistent.org/blog/happy-10th-anniversary-p...

As Jon Orwant (supposedly) said in 2000 (quoting from the article you linked):

> we are fucked unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things

I honestly don't remember. Nor do I care anymore. :)

Yeah, Perl 6 created a lot of confusion especially inside the Perl 5 community. But, in the end, they figured it all out: Perl 5 lives on and Perl 6 got out of its way by renaming itself to Raku. And, for the record: Raku itself is a gem of a language, I believe. A pretty solid OO system, optional typing, powerful language constructs, stellar Unicode support and somehow it is still staying true to Perl's rather pragmatic and, if I may say so, libertarian approach to software developing. I personally love raku's "grammars" most because they render writing parsers a routine job, it's amazing and no other programming language provides such a feature.

If you're interested I strongly suggest you to check out Brian D Foy's book on Raku: https://www.oreilly.com/library/view/learning-perl-6/9781491....

How about the reported Perl6 / Raku speed issues? Saying "reported" because I have not done an in-depth study if they exist, just read about it briefly somewhere (and a while ago, may a year or so). If they did/do exist, was/is anything being done about them? Asking because I, for one, found both Perl 5 and 6 interesting, and the language features of both, somewhat unusual and powerful.

Raku is a significantly higher level language than most languages. Which tends to lead to slowness.

Really it's faster in many places than it has any right to.

    @a[1];

Is just shorthand for a subroutine call.

    postcircumfix:< [ ] >( @a, 1 );

Which ends up calling a method.

    @a.AT-POS( 1 );

Actually that is also a simplification as AT-POS is probably a multi method. Not to mention inheritance.

There is even a level under that, NQP. (simplified example below)

    my $reified := nqp::getattr(@a, List, '$!reified');
    my $result  := nqp::atpos($reified, $pos);

All of those levels of indirection have a cost associated with them.

---

It just Rakudo on MoarVM has a bunch of optimizations to remove the needed complexity at some point. Either during compilation, or after it's been running for a while.

So with those optimizations it can sometimes beat other higher level languages. (For some specific uses it may even sometimes meet or exceed the speed of low level languages like C/C++. Mainly for algorithmic reasons.)

More optimizations would always be nice though.

Interesting. Thanks for the reply. Just saw it now. I get it.

I think Raku is still quite a bit slower. But I am not up-to-date with the latest state. However, this is "just" a matter of optimization of the interpreter over time. It's just that Perl 5's interpreter had a head start of more than 25 years.

Yes, that is possible. Java was dead slow early on (I first used it soon after it came out, and pioneered use of servlets in my company at the time), but after Sun's management threw millions of dollars and high-end tech people at the problem, it got fast enough for many uses in a few years, what with the Hotspot VM and JIT tech and so on.

Sorry, the millions of dollars was mostly for marketing (which is largely what led to its huge adoption), but at least some of that money would have been used to hire top people like computer science compiler specialist PhDs to work on making it faster. I had read about that at around that time.

Raku outperforms perl5 and cpython on quite a few benchmarks, and has for a couple of years now. Some of the ‘nice’ features have pathological performance, but if it becomes a problem in practice you have recourse.

Hope so. Want to try it out. I bought and read most of the llama and camel books years ago, at Perl v4 or so. Ditto for the Perl Cookbook. (All 3 by O'Reilly. Some of those Cookbooks were very good. Also had the Python and Java Cookbooks.)

Enjoyed them (the Perl books). But didn't get a chance to use Perl in non-trivial real projects.

I recommend going to https://raku.org/ and reading up on the language because Raku actually has features “modern languages” do not. E.G. the grammars.

I don't remember anyone paying much attention to perl6 before long after perl had peaked. It was for a while seen as an potential savior for perl but that faded too.

It was more about PHP, Ruby and Python entering the stage and diluting the market for scripting languages by each offering something special that one set of users really wanted weather it be an easier deployment path better standard libraries or a more beginner friendly community.

There is no "wonder". They did.

I did a fair amount of Perl just over a decade ago but can't really see any situation where I'd reach for it over Ruby now. Ruby has Perl's text manipulation goodness with a saner syntax.

Performance.

Perl was a legit tool in bioinformatics due to its insane text parsing performance. Ruby performance is absolute garbage.

I learned Perl in the mid 2000s because I was working with a company that took text (and sometimes spreadsheet) dumps of public records data and processed them into a database. The entire ETL pipeline was a set of Perl scripts, and, as far as I know, that system is still running. The Perl iteration was actually the second iteration of that system - the first iteration was a set of C programs and shell scripts that were replaced over time.

The rich ecosystem of tested Perl modules for file formats along with the testing frameworks made coping with change bearable - not enjoyable, but bearable.

Oh man the ecosystem. I still think CPAN set the bar for what a high-quality language ecosystem should look like. npm and rubygems look like amateur hour by comparison.

And ubiquity: there’s a Perl for almost all systems

I wonder for how long..

> I wonder for how long..

Is anything ever really taken out of /usr/bin once it gets in there? It may be a long long /usr/bin/time.

OpenBSD ships it by default, with Pledge support.

I still do my NLP preprocessing in perl for this exact reason

Do they have to enter the modern world and compete with the modern languages?

Personally, I’d like them to focus on shell scripting and tool making. (But that’s what I use Perl for, so of course I’d say that)

Ironically making it more modern may make things like shell scripting easier.

Let's say that Perl gets a real type system, and reflection capabilities.

Then I can see something like this come to exist:

    use v7;
    use GetOpt::MAIN;

    sub MAIN ( str $name, int $count ) {
      say $name for 1..$count
    }

They don’t have to, but it seems to be their stated goal.

I wrote a ton of Perl as well, but that stopped long ago. In the meantime I've learned a number of languages, Python and Ruby included. Maybe what they're doing is enough to slow down the decay in terms of user base. But I'd be shocked if it reversed it either by bringing old Perl users back or getting new ones.

Of course, it could just be that this is an internally focused text. Maybe there's some other document that explains a product vision that says, "Perl will be better at X,Y, and Z for groups A, B, and C"?

This document is mostly discussing how they can deliver on a product vision without breaking existing code too badly. The product vision would be a different document of which features to add and why.

Oh, sure. But does that different document exist?

Excellent question. I think a big part of the customer story is eventually getting a standardized object model like Corinna into the core language. I do know a lot of objections to Perl have come from the bare-bones built-in objects and the dozen or so ways to build on those using CPAN modules. Getting signatures in rather than the older function prototypes is another. I don't know that there is a unified vision for what future Perl will be yet, other than something that surprises people coming from other languages a lot less yet remains Perl.

Thanks for the comment. I'd say that sounds like a good start. But making it easier for people to switch to Perl is still different than giving people reasons to switch to Perl.

For example, at my current job we picked Python as our default language because a) it's a solid language, and b) since we're doing exploratory ML work, Python's dominance in the ML and data science worlds means good tools and a strong community. Previously I switched to Ruby because a) it's a solid language, and b) Rails made it really easy to build the sort of web stuff we were building at the time. Or when I was building a mobile app I went with Dart and Flutter because it was the only decent-looking platform that would let me do cross-platform development as a solo developer, and it seemed like Google was serious about making it happen.

So I think Perl has to answer the question: whose problems are we going to solve better than anybody else? From what I've seen over the years, it looks like the answer is "people still using Perl". Which is not a terrible answer; it serves for the COBOL and Fortran communities.

Well, Perl is still a solid and improved replacement for sed, awk, and shell. PSGI puts it about on par with other platforms for persistent web apps with Mojolicious, Catalyst, and Dancer all solid frameworks for that.

It's reasonably performant. It has true multithreading with no GIL and handles multi-process programming well too. For several years the regex engine has been iterative except for places like backtracking that pretty much need to still be recursive. It's among the fastest language systems that do reflection and offer true closures and lambdas. It used to be faster than a whole lot of other languages, but lots of other have made more progress on that front. Deprecating some features and being willing to break compatibility will allow more optimizations in the compiler and opcode interpreter.

It does portable deployments really well with perlbrew. Or if you want just an easily deployable app, there's Carton. Strawberry Perl works on Windows pretty identically to how perl works on Linux or BSD. Perl runs fine on Android, although it can be a little memory-heavy for constrained devices.

One of the killer features for me is CPAN and in particular metacpan, cpanm, and CPANTesters. Having the code, docs, star ratings, and a matric of which versions are passing all test on which platform all in one place with a good search engine in front of it is really handy. NPM came a lot later for example and still doesn't have things like version pinning and local re-vendoring worked out.

As for what's going to grab a lot of new developers or lead a lot of established developers away from their current preferred languages, I really don't know. If I was starting today and looking for one primary language that was fast to develop, reasonably fast in production, full-featured as a language, and had great library support I might go with Julia, OCaml, F#, Common Lisp, Ruby, JS/Node, Racket, or Scala Native. Maybe even Pike or Lua (Lua since its FFI is so strong any C library is basically also a Lua library).

I'm someone who's been using Perl as one of my primary languages since the 1990s. It's one of my top 4 or 5 languages, and for whole classes of problems it's what I reach for first - at least for prototyping something out. I really like Raku, which has great performance in spots but is still very slow in parts of the language. That language's killer app so far is parsers, by a long shot. Since I'm still using Perl for many things, a cleaner, faster, less crufty Perl would be a great thing. I also think since most of Perl's strengths are still fairly well known but some of the more arcane things like output formats, tied variables in the core, and the core object syntax being kind of raw and under-opinioned are considered too crufty to overlook that cleaning those up might be enough to grab the attention of people who might be on the fence.

maybe https://youtu.be/6wPMh-3qYJM?t=3837 (5:47 - 1:03:52) (meanwhile obsolete)