Yeah, I agree with you. For fun I built Perl 1 a couple years ago and was amazed at how similar it was to Perl 5. In fact most of the test suite from Perl 1 runs unmodified on Perl 5. The subroutine calling syntax was different (it used `do xxx();` I think) so those tests fail.

But unfortunately, some Perl devs in recent years keep thinking that what they need to do is break stuff to "modernize". They keep eyeing goals like turning `strict` on by default, and eliminating lesser-used features, which will surely break untold numbers of 20-year-old scripts.

I think there is some low-level anxiety among some of their developers that interest in their language has basically evaporated and they keep reaching for a silver bullet that doesn't exist. I think they are crazy ("perl 7... now 10% more like python!") but it's open-source so in the worst case I'm sure someone will keep a traditional perl from bit-rotting.

edit: I had made a short blog post about playing with perl 1: https://rwtodd.org/2020/Jun/building-perl-1

> They keep eyeing goals like turning `strict` on by default

Not unless you declare a version. Old style perl will continue to work as before.

If you declare something like:

    use v5.40;

... then, and only then, you'll get strict/warnings/whatever turned on.

Your 20 year old script can continue to run just fine.

That doesn't really capture what's been happening. If feature bundles are still today's plan, it's only because the multiple attempts to get strict on by default have so far all been defeated. They are still pushing forward adding options to disable features like indirect calls, multidimensional hashes, bareword filehandles, etc. And you can bet that at some point they will revive the idea of moving to Perl7/8/9 and permanently remove those things as they go.

Some--not all--of the people working on perl really want so-called "cruft" to disappear. I'm not a fan of that attitude for such an old language with such a rich history of backwards-compatibility, and I definitely don't think it's going to accomplish some kind of perl renaissance. I think it would be better to double down on what makes perl unique. When I watch Signes giving a talk like https://www.youtube.com/watch?v=FlGpiS39NMY where he shakes his head at variables like `$;` or `$,` (29:20 in the video) ... it looks like the leaders of perl hate how strange it is. That worries people like me, who love perl _because_ of its quirkiness, not in spite of it. Surely people who want something more consistent have moved to Ruby long ago.

> They are still pushing forward adding options to disable features like indirect calls, multidimensional hashes, bareword filehandles, etc.

Personally, so long as all that stuff's behind a feature bundle I'm all in favour of it.

A little nitpick: it's not about "multidimensional hashes", but rather "multidimensional array emulation". Steer clear of it, if you can.

I personally don't mind using variables like $; or whatever. Some prefer to "use English" and use longer variables name for the same effect. More power to them.

I just wrap the call with the proper "## no critic (...)" and off I go.

Well, there's certainly a deprecation cycle in play, and some things may be on their way out that I would rather see kept around (e.g. they seem to have given up on getting the case statement-- given/when-- working: it's tough to do it right without built-in types), but seriously you seem to be behind-the-times on how the project is being managed. If they implement a version 7.0 scheme again, I guarantee they'll do it without breakage: you'll need to say "use v7;" to turn it on.

I have a feeling you're reading Richardo Signes wrong, by the way-- he likes to play up what a negative kind-of-guy he is, and makes critical remarks about the state-of-perl in public that some people take a little too seriously. Perl-haters gotta hate, and they really loved to link to his talk with the title about how perl is an "Ongoing Disaster" or some such.

Hopefully you are right about all of this. I don't follow it closely, but when I periodically check in on nntp.perl.org I get the feeling they have no idea what to do about v7 anymore. Since they have to say _something_, currently they say they have no concrete plans but won't change defaults. We will see.

Feature bundles don't bother me, but if I read between the lines (possibly too much), comments they make seem like they are still looking for an opening to remove some of these features entirely. I hope I'm wrong.

(I remember the Ongoing Disaster talk, I personally thought it was fun)

Factual sources:

https://gist.github.com/Grinnz/be5db6b1d54b22d8e21c975d68d7a...

https://github.com/Perl/perl5/wiki/Perl7-FAQ

last time, I saw they say perl 7 will waiting for some features finishing, e.g., new OOP system in core

"But unfortunately, some Perl devs in recent years keep thinking that what they need to do is break stuff to 'modernize'. They keep eyeing goals like turning `strict` on by default, and eliminating lesser-used features ..."

There was some talk about that a few years back, but those ideas have largely been abandoned. They've also adopted the "steering committee" approach, and they have something like a formal RFC proceedure to talk over new proposals-- in general the project is in very good shape. And backwards compatibility is still the rule, unlike a lot of other projects out there.

> But unfortunately, some Perl devs in recent years keep thinking that what they need to do is break stuff to "modernize".

Isn't it the whole point of Raku (previously Perl 6)?

Indeed it was. But no more. The Perl community has decided to make many of the mistakes again. It is very frustrating.

Curious - is there a reason to use Perl (Wall's latest version, 5 or whatever) in 2022 if one has no familiarity with the language? What would be the major advantage of using Perl over its closest analogues, some bastardization of Bash and Python?

Well, Larry Wall's latest project was called "Perl 6" but has been renamed "Raku"-- in belated recognition that it really is a new language, and Perl is going to continue being Perl.

The main reason to learn Raku at present is simply that it's profoundly different from most other things out there-- there's no particular "killer app" that's emerged for it, but it's unusual enough that this might happen yet (no one expected Perl would be critical for "Web 1.0" and the Human Genome Project...).

Some Raku features:

(1) it's numeric types include true rational numbers, so there's less chance of being tripped up by floating point approximations (e.g. 2/3 is really 2/3, and if you multiply by 3 later you get precisely 2). It also does big integers by default: you're less likely to have overflow problems.

(2) Raku's regular expressions have been redesigned from scratch, and it ships with expanded capabilities to compose them into larger structures called "grammars": Raku is a uniquely powerful tool for writing special-purpose parsers, ala domain-specific languages. (Note: this is how Raku parses itself-- it's not implemented in the usual lex and yacc style.)

(3) Extremly convenient features for handling CAP (concurrency, asynchrony, parallelism), possibly the easiest to use of any language.

As for Perl (meaning the original, Perl 5), it's vastly superior to traditional bash scripting because all the components were brought into one process where they could be made more consistent and talk to each other easily.

How Perl compares to Python is a little difficult for me to answer: I prefer Perl, but I could be biased on this one, and there's no question Python has quite a bit of momentum at present in a number of areas.

Thank you to provide 1, 2, 3 above. I didn't know about these!

I am surprised you didn't mention Perl 11 which is try to mash Perl 5 and 6/Raku together. Is that still happening? Or do I have it wrong?

"How Perl compares to Python": The first thing I tell Perl programmers who are starting to learn Python: There are Perl-style references in Python. (If you are not familiar with Perl: These are a roughly pointers, and can be 'undefined' / null.) In short: You cannot create a reference to a scalar in Python. Perl hackers then scratch their head and ask, "Well then, how do I build XYZ data structure without...?" The easy workaround is a single element tuple or list. "Aha!" Otherwise, Perl programmers can adapt very quickly to Python.

perl 11 is dead. It was never much more than a mirage by a few people outside of the Perl community. It was definitely not something supported by what is now the Raku community.

Ruby is a much more hospitable environment for ex-Perl people, IMHO.

I was 50/50 in 2011 between Python and Ruby (Django / Rails). Went with python in the end, kind of glad I did. Ruby has fallen off a lot in popularity, while python hasn't. Also Python seems to be a lot more general purpose, while ruby is a lot more web development focused.

Sorry, I cannot edit. I meant to say: There are no Perl-style references in Python.

This is one way to think about it. If you take your glasses off and squint a little, underneath perl and python work in extremely similar ways, and basically do the same thing. Python is a dynamic language created to provide uniformity of syntax. Perl is a dynamic language designed to provide flexibility of syntax - wherein it has natural language features like list/scalar context.

Both of these approaches have their advantages. I have a saying I overuse: "Python helps you think more like the computer does, Perl helps the computer think more like you do". The consequence of this is that python is good at helping people think about tasks that the computer is good at in - like statistical problems. On the other hand perl is good at helping to contain the mess and chaos of the real world in a way that makes it more tractable for the computer - which is why it remains popular in the recruitment industry backends and other less tidy business areas.

Perl's very raw unvarnished object model is in fact based on python's, so it is very similar, but it's also built for flexibility. This means object models like Moo[1] which are really nice flexible and done right make it really easy to write extendable applications. Implementing python's object model in perl (i.e pretty much the exact specification) is easy. However you can't implement perl's object model in python except by messing with the guts of the python interpreter.

I haven't done any commercial python - I only have a passing aquaintance really from messing with sympy and the like. But boy perl has been good to me. I earn a good living in an interesting job and I can maintain interests out of work as well. And I haven't had to look hard for work for years. Of course currently I'm neck deep in recursive SQL queries.

[1] https://metacpan.org/pod/Moo - My favourite job to date was building a back end to spin up network devices, that got one gentle refactor after the initial implementation and was then subsequently extended to three or four completely different network device architectures extremely quickly. Mostly by virtue of making almost every object property read only and memoised on demand (extensions to existing methods would are likewise inlined on complilation - all done with object composition rather than inheritance too for an added layer of sanity)

You can think of Perl as a super AWK. That's really the genesis of it's design philosophy, hence all the special automatic variables and modes to implement processing loops on the command line. From a scripting standpoint, the language is designed to be used with much less ceremony than Python and its ilk.

I use Perl over Bash because I'm more familiar with the C-like, PHP-like syntax with parentheses, curly braces, if/else, while, and sigils. I'm also a fan of both strict and taint, which have saved me countless hours.

I use Perl over Python because of the culture/tradition of not introducing breaking changes into the language/runtime, which has also saved me countless hours. I'm also a fan of arbitrary whitespace for formatting.

Perl is ubiquitous in the *nix world. Combined with its stability and my avoidance of third-party libraries, I can run my scripts basically anywhere without struggling with dependencies, version mismatches, etc.

* Unicode's high hanging fruits implemented competently and correctly

* not grinding a theoretical axe against the user

* language changeable at run-time to some degree, so stealing new ideas from other languages and keeping up with advancements in PLT can be and is done by end users, not only the maintainers

I don't write any Perl scripts these days, but I still use Perl one-liners frequently at a Bash command prompt and in Bash shell scripts.

Example: Convert Windows newlines to UNIX newlines: $ ... | perl -p -e 's/\r\n/\n/g' | ...

My brain is too full to remember how to do similar regexy transformations using sed, but I know it can be done.

>> Curious - is there a reason to use Perl (Wall's latest version, 5 or whatever) in 2022 if one has no familiarity with the language? What would be the major advantage of using Perl over its closest analogues, some bastardization of Bash and Python?

It depends on what you are trying to do.

Perl excels at processing text particularly if you are familiar with regular expressions.

Perl mainstreamed regular expressions and most programming languages that support regular expressions support some subset of Perl regular expressions.

Perl is faster than both Bash and Python and scales up a bit better than Python as a project starts to grow because 'use strict' and 'use warnings' will catch many errors. Python has a better 'batteries included' standard library, so it tends to be better at prototyping than Perl unless you are pulling in libraries in which case it depends on what you are trying to do.

Perl can be more terse than Python, particularly if you are using built-in variables. However, this impacts legibility which is part of the reason why Perl is the target of 'executable line noise' jokes.

I don't know if its backwards compatibility reaches into the 90s but I've been using ruby for this for like a decade now. Most envs that ship with anything ship with ruby and I've only very rarely run into version problems.

I think people tend to associate it only with a certain era of web dev, but it has remained a good scripting language with a large, consistent, well-documented standard library for a long time now.

Not worth switching off perl since you're very used to that, but iirc ruby was initially conceived as a successor to perl and for me at least it has landed in that role.

Ruby is a fantastic scripting language and I generally use it instead of Perl but for the ugliest corner cases, character encoding gotchas, *nix system oddities, etc I frequently find someone from the Perl community has had my problem and solved it with a regex.

I think it's the sysadmin culture. If your scripts are used by thousands of different servers hosting custom web apps and strange databases you'll run into every possible bug fast.

Ruby is great, and I know people who swear by it, but I've yet to come across a GNU/Linux distro which didn't come with Perl installed, while Ruby is not a given in the default, e.g. my current Manjaro.

The compatibility really does stretch back all the way to '94.

On OpenBSD, some of the scripts or utils (mandoc) are written in Perl because the developers prefer it. There have been some email chains on the mailing lists about having Perl in base. Most of them are interesting to read.

The pkg_* suite it's written in Perl.

TeX has stability to compare. But, stability is seen as a goal for that project.

I only touched Perl a little bit, at the start of my career in the mid-to-late 00s. I didn't hate it. For our specific use case, which was generating reports from large groups of text-based log files, it was wonderful.

I'm curious, though, do you have any Perl programs you've worked on recently that are public? I'd love to take a look at how people are writing Perl these days...

check my profile :)

template default perl

> I use almost none of its more esoteric features

Which features do you see as esoteric?

To me, it means features which would not be obvious to me in their function coming from a PHP/C/VB/Java background.

I typically write code which I can (and do) copy and paste into PHP almost without changes. (I use PHP as both webserver glue and for duplicating functionality so that I can have two copies of the same code to validate against each other.)

I've also started adding some Python to my project and developed a very similar style in Python, using commented curly braces to reduce the code's brittleness.