In a +1 score to #Perl's great back-compatibility, I've had a script called from procmail that's been 100% reliable for the past 15 years maintaining my email, over many years of regular Perl updates.
A month ago it broke - because procmail. https://github.com/BuGlessRB/procmail/issues/5
But the perl itself still runs absolutely fine.
Variable set with stdin pipe action fails leaving empty variable · Issue #5 · BuGlessRB/procmail
Hi. After I updated procmail to version 3.24 in Debian, I received the following report from Bob Proulx which I believe deserves attention: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028356...GitHub
reshared this
Christos Argyropoulos MD, PhD
in reply to Paul Evans • • •Mark Gardner reshared this.
Paul Evans
in reply to Christos Argyropoulos MD, PhD • • •@ChristosArgyrop I do really wish we - the Perl community - were much much louder about this strong back-compat stuff.
You can update your perl and everything keeps running just as it did.
We really need to be shouting this from the hills.
Mark Gardner reshared this.
Christos Argyropoulos MD, PhD
in reply to Paul Evans • • •#Perl DOES need to fix some performance issues and incorporate static types to come to the 21st century without breaking stuff, but no one can beat it in terms of reliability
Peter Jakobs ⛵
in reply to Paul Evans • • •Paul Evans
in reply to Peter Jakobs ⛵ • • •@pjakobs Yeah I get that. People ask me what is the Perl equivalent of pyenv, and I ask what it does, and they explain and then I wonder "Uhm, I don't know, I've never felt a need to have that in Perl".
They wonder how I maintain different versions of Perl for different things and I say "I dunno, I just use latest for everything and it all works fine". I get these sortof blank stares of disbelief.
Mark Gardner reshared this.
Peter Jakobs ⛵
in reply to Paul Evans • • •I only wish there was a stronger concept of multi threading in perl.
Paul Evans
in reply to Peter Jakobs ⛵ • • •@pjakobs We have some excellent async/await stuff that I reliably use across lots of my personal code and I'm aware companies do use for real data stuff - sometimes large amounts of it. There was a billion-row Postgres database migration using it, for example.
https://metacpan.org/pod/Future::AsyncAwait
Future::AsyncAwait
metacpan.orgPeter Jakobs ⛵
in reply to Paul Evans • • •Paul Evans
in reply to Peter Jakobs ⛵ • • •Peter Jakobs ⛵
in reply to Paul Evans • • •I'm aware, but I've seen situations when a single cpu thread was not enough oomph to handle a large event queue, for example. If more comes in than one core can handle in any given time, the order gets less relevant.
I know, this is not a typical perl use case, but it it works pretty reliably.
And - since I'm currently working in JavaScript - perl code is so much prettier and easier to read!
https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl
fhem.pl in trunk/fhem – fhem
svn.fhem.dePaul Evans
in reply to Peter Jakobs ⛵ • • •@pjakobs Ahyeah if you have smaller comput-heavy tasks that need to be asked a question and send back a result but are otherwise stateless in terms of intermediate working, then there are also nice async solutions for that.
https://metacpan.org/pod/IO::Async::Function
IO::Async::Function
metacpan.orgPeter Jakobs ⛵
in reply to Paul Evans • • •Mark Gardner
in reply to Paul Evans • • •I mainly manage different #Perl versions with #asdf (https://asdf-vm.com) to test code that has to run in less upgradeable environments elsewhere. $work, for example, susbscribes to #Canonical's #Ubuntu Pro so we're on Perl v5.34.0 of their 22.04 LTS #Linux distribution (“#Jammy Jellyfish”).
But like @leonerd, personal stuff is on the latest.
asdf | asdf
asdf-vm.comChristos Argyropoulos MD, PhD
in reply to Mark Gardner • • •Mark Gardner
in reply to Christos Argyropoulos MD, PhD • • •@ChristosArgyrop @pjakobs #!/usr/bin/env perl
is the typical way to call whatever #perl happens to be first in your environment's path
The nice thing about #asdf is it reads a `.tool-versions` file in a given project's directory and will use the specified perl, ruby, node, whatever version via its shim scripts: https://asdf-vm.com/guide/getting-started.html#_6-set-a-version
I used to use #plenv, which is like #perlbrew plus asdf but for Perl only: https://github.com/tokuhirom/plenv
GitHub - tokuhirom/plenv: Perl binary manager
GitHubChris (so far)
in reply to Mark Gardner • • •I use plenv in my development environments, and whenever I have a machine that has the misfortune of me being its admin. I specifically use plenv because it supports the .perl-version file so I can commit that to the repo.
I also heavily use Carton so all my libraries are installed in a local/ directory.
My production environment is containerized so I used the perl:latest Docker image.
Chris (so far)
in reply to Chris (so far) • • •Mark Gardner
in reply to Chris (so far) • • •Paul Evans
in reply to Mark Gardner • • •Experimental just means "we might change or remove it later". if you have no long-term requirements on the code and it only has to solve this-month's problem, using experimental is fine.
You just don't get to complain if next year's update breaks it. Experimental simply means "not covered by Perl's otherwise-excellent back-compat guarantees". I.e. everything you get from most other languages
Random Geek
in reply to Christos Argyropoulos MD, PhD • • •@ChristosArgyrop @mjgardner @pjakobs@mastodon.green I usually set up plenv, rbenv, and pyenv on a new Linux install, but mainly for Perl it's just
plenv install <latest>, and at some pointplenv migrate-modules <old-latest> <new-latest>But my Perl workflow is strictly personal stuff these days, so precise project dependencies haven't been a concern.
Mark Gardner
in reply to Random Geek • • •GitHub - asdf-vm/asdf-plugins: Convenience shortname repository for asdf community plugins
GitHubChristos Argyropoulos MD, PhD
in reply to Mark Gardner • • •Mark Gardner
in reply to Christos Argyropoulos MD, PhD • • •Christos Argyropoulos MD, PhD
in reply to Mark Gardner • • •(Again very stupid question, but paths are one of the most painful things in the universe for portability)
Mark Gardner
in reply to Christos Argyropoulos MD, PhD • • •Jon Barber
in reply to Mark Gardner • • •mcgrew
in reply to Paul Evans • • •@pjakobs to be honest I think the pyenv users are crazy. I've been developing in Python for 20 years and I've never used it.
Migrating from Python 2 to Python 3 did break a lot of stuff, but aside from that I seldom have a problem. I suppose third party libraries do sometimes break things, but that's not really Python's fault.
I think the problem stems from the over-introduction of dependencies. I blame java & typescript devs for that culture.
Raptor :gamedev:
in reply to mcgrew • • •Paul Evans
in reply to Raptor :gamedev: • • •jwz
in reply to Paul Evans • • •reshared this
Olaf Alders and Mark Gardner reshared this.
Paul Evans
in reply to jwz • • •Steve Downey
in reply to jwz • • •Entirely abandoning the perl6 project while perl5 was unchanged for a decade has a lot to do with all this.
Paul Evans
in reply to Steve Downey • • •@Sdowney @jwz @pjakobs Yeah; that whole "Perl 6" distraction was unfortunate, yes. That particular project has now been renamed Raku thus leaving Perl a clear runway to bump the version number up to 7 and onwards someday, so it's at least fixed now.
Though sure that reputation still hangs around far longer... Not a lot we can do about that, besides trying to override it with more positive noises now.
Steve Downey
in reply to Paul Evans • • •Paul Evans
in reply to Steve Downey • • •@Sdowney @jwz @pjakobs A charitable way to consider it, is that it split the group into "make new thing" and "keep existing thing" camps.
In reality I fear the outcome was more that it also created a third camp of "screw this I'm off elsewhere", and a lot of otherwise-good devs just disappeared.
It's certainly a regrettable part of history I wish had not happened. But then you can say that of a lot of historical happenings ;)
jwz
in reply to Paul Evans • • •Mark Gardner reshared this.
Peter Jakobs ⛵
in reply to jwz • • •Mark Gardner
in reply to Peter Jakobs ⛵ • • •I think it’s charitable to the #Perl 6 splitters. The Golgafrinchan Ark B group in "The Hitchhiker's Guide to the Galaxy" was mostly harmless 😉 (and useless); the #Perl6 effort was, at best, neglecting #Perl5 compatibility, and at worst, actively throwing bombs at it.
#h2g2
Steve Downey
in reply to Mark Gardner • • •Mark Gardner
in reply to Steve Downey • • •Peter Jakobs ⛵
in reply to Mark Gardner • • •Mark Gardner
in reply to Paul Evans • • •To @leonerd’s first point, #Perl6 was renamed #RakuLang in 2019 after @lizmat finally realized that “#Perl" in the name was "confusing and irritating" to all concerned:
https://news.perlfoundation.org/post/tpf-response-raku-rename
https://github.com/Raku/problem-solving/issues/81
It was not abandoned, @Sdowney.
"Perl" in the name "Perl 6" is confusing and irritating · Issue #81 · Raku/problem-solving
GitHubMark Gardner
in reply to Mark Gardner • • •I just noticed Damian Conway’s comment that #RakuLang (then #Perl6) intended to be “a hundred-year [#programming] language”: https://github.com/Raku/problem-solving/issues/81#issuecomment-519776528
IMHO that points to the heart of why the Perl 6 effort was so disastrous for the #Perl community: it tried to create a hundred-year language by burning a decade+-old language for fifteen years.
"Perl" in the name "Perl 6" is confusing and irritating · Issue #81 · Raku/problem-solving
GitHubSteve Downey
in reply to Mark Gardner • • •@mjgardner @jwz @pjakobs @lizmat
A COMPLEX SYSTEM THAT WORKS IS INVARIABLY FOUND TO HAVE EVOLVED FROM A SIMPLE SYSTEM THAT WORKED
A COMPLEX SYSTEM DESIGNED FROM SCRATCH NEVER WORKS AND CANNOT BE MADE TO WORK. YOU HAVE TO START OVER, BEGINNING WITH A WORKING SIMPLE SYSTEM
John Gall, Systemantics: The Systems Bible
Dave Jacoby
in reply to Steve Downey • • •Mark Gardner
in reply to Dave Jacoby • • •@jwz @pjakobs To @jacobydave’s point, here are the receipts:
* 2000, v5.6: https://perldoc.perl.org/perl56delta
* 2002, v5.8: https://perldoc.perl.org/perl58delta
(#Perl6 Osbornes the air out of the room for a bit)
* 2007, v5.10: https://perldoc.perl.org/perl5100delta
* 2010, v5.12: https://perldoc.perl.org/perl5120delta
From there it's a new major version like clockwork every year.
So the only thing that didn't change for a decade was @Sdowney's opinion of #Perl.
perl56delta - what's new for perl v5.6.0 - Perldoc Browser
perldoc.perl.orgPaul Evans
in reply to Mark Gardner • • •Shiar
in reply to Mark Gardner • • •perl version cheat sheet
sheet.shiar.nlWanja
in reply to Paul Evans • • •@pjakobs I've used a lot of different languages over the years, and while a bunch of them had breaking changes once in a while, Python was really the worst of them.
I used to be a professional Python dev and still maintain a few Python projects now. Every single minor version bump breaks at least one of them. And somehow other Python folks finds this normal. It's not, every other language does not need a pyenv!
Steven D. Brewer 🏳️⚧️
in reply to Paul Evans • • •Paul Evans
in reply to Steven D. Brewer 🏳️⚧️ • • •@stevendbrewer @pjakobs Sure, people write new stuff.
But how often did installing a newer one break something existing so you had to go back to an older version? That's basically unheardof in the #Perl ecosystem. The language, the modules, everything. You are always confident that you can update to newer things to get newer features and know that existing stuff does not break.
Peter Jakobs ⛵
in reply to Paul Evans • • •actually, through this discussion, I wonder:
is that because perl itself is not changing that much at the core, making the whole ecosystem more stable (I remeber I just read an interview with Larry Wall where he said that core changes were few and far between)
or is it because the ecosystem is just better managed than in python?
@stevendbrewer
Paul Evans
in reply to Peter Jakobs ⛵ • • •@pjakobs @stevendbrewer Oh no, we're adding more things all the time. 5.36 for example added *loads* of stuff. It's just all far better managed.
Primarily, we have this `use VERSION` mechanism, where files say what version of Perl they're expecting, so any updated features, new keywords, etc... aren't made visible to files expecting older versions of the language.
https://perldoc.perl.org/functions/use#use-VERSION
use - Perldoc Browser
perldoc.perl.orgDaniel Thomas
in reply to Paul Evans • • •Cassandrich
in reply to Paul Evans • • •Paul Evans
in reply to Cassandrich • • •@dalias @pjakobs Sure but that's still "language culture". The entire culture around Perl is that back-compat is important and breaking things like that is just not on.
I'm not saying it's universally respected, but you'll find that most authors most of the time do that that kind of thing seriously. It's not *just* the core language, it's the entire ecosystem.
Cassandrich
in reply to Paul Evans • • •Paul Evans
in reply to Cassandrich • • •@dalias @pjakobs One thing I learned by losing the RNCH ("Real Names Considered Harmful") arguments in Google (which eventually got my fired), is that one person - or a small group - can very rarely actually alter the ingrained culture of a far bigger group.
In the case of Python developers, I think the culture is just to "go fast and break stuff", even if that means the code you wrote last week no longer works. It's just considered normal there.
Cassandrich
in reply to Paul Evans • • •lc_lol
in reply to Paul Evans • • •@dalias @pjakobs
Since DLLs and so, some devs have found it perfectly natural to force users into installing and maintaining a huge and messy amount of various libs, versions, files (...) on their computers.
But no other language ever managed to bring even half the mess python does. Just looking for "python" in your filesystem or packages database shows how far they went.
matsuzine
in reply to Paul Evans • • •I deal with this constantly at work. Python, PHP, Node, Ruby. And you're right, it's not only (or even primarily?) a problem of backwards compatibility in the core language, it's a culture of constant change in the libraries. Nothing is stable.
I actually believe this is Perl's killer feature, and a main reason I choose it.
Ryan McCuaig
in reply to Paul Evans • • •Hugo Mills
in reply to Paul Evans • • •@pjakobs I've rarely, if ever, felt the need to use venvs in python, either. It's always felt to me like a tool looking for a problem. Sadly, it's one that's now penetrated the entire culture, to the extent that people use them by default even if there's no actual problem.
It drives me nuts that it's now being made mandatory to use the damn things in Debian. I can't just install a package, and just run my python code that uses it, because... reasons?
Anton Piatek
in reply to Paul Evans • • •Paul Evans
in reply to Anton Piatek • • •@sldrant @pjakobs It is very very rare. A big part of why is what we call the Blead-Breaks-CPAN system, BBC.
It checks CPAN modules against upcoming Perl releases, meaning we can know before the actual release, if it causes things in CPAN module tests to break that used to work. Over the past several years of releases I can recall many actual issues that has found and fixed, so users never noticed.
Paul Evans
in reply to Paul Evans • • •Chris Dillon 🌹
in reply to Paul Evans • • •Ryan Finnie
in reply to Paul Evans • • •penryu
in reply to Paul Evans • • •@pjakobs True. The key being that Perl hasn't really changed (at least not in any way that would really break code) in 20+years.
I never really understood why a language so ostensibly simple and straightforward as Python couldn't do the same.
Josh Dick
in reply to Paul Evans • • •Jean-Baptiste "JBQ" Quéru
in reply to Paul Evans • • •Chris
in reply to Paul Evans • • •FirefighterGeek :masto:
in reply to Paul Evans • • •Lotus Notes (aka IBM Notes) (aka HCL Notes) and the "Domino" versions of each has been 100% backward compatible since the early 90s.
It has not stopped the products from losing market share.
purple 👊✊💨
in reply to Paul Evans • • •the only personal application i've written to make it to version 1.0 and see distribution was written in perl. i picked perl because i know i won't have to spend the rest of my life keeping track of dependencies.
folks don't realize perl is the duct tape holding the internet together.
Mark Gardner reshared this.
Paul Evans
in reply to purple 👊✊💨 • • •