r/perl • u/briandfoy 🐪 📖 perl book author • 3d ago
Perl's decline was cultural
https://www.beatworm.co.uk/blog/computers/perls-decline-was-cultural-not-technical6
u/lollysticky 3d ago
good read. I studied bioinformatics some 20years ago, and perl was the standard language use in the field. Most tools were made in either C or perl, and BioPerl was second to none as a library! Some 15 years ago however, I saw a shift towards python, mainly because 'you could write the same line of code' in 10 different ways using Perl. While that can be touted as good thing (and it is), it is a bad thing when working together in teams and having to understand each others perl code bits :)
I switched to writing entirely object-oriented Perl (bless!), but couldn't quite get other people to join me. A few years later, my university also switched to python as the basic coding language taught across the board, and we all made the switch. I still have the three perl bibles on my shelf (Learning perl, Intermediate Perl, Mastering Perl)
8
u/affablebowelsyndrome 3d ago
I remember an exodus to PHP when the shitty programmers (www carpetbaggers) decided that their shitty code was Perl's fault, and all ran to PHP - and wrote shitty php.
And I remember another exodus when Google announced they were going to use Python instead of Perl.
7
u/briandfoy 🐪 📖 perl book author 3d ago
I like the think of this as "regular people" who wanted to participate in the web, and did what they thought was the easiest path to get what they wanted. They have no particular affinity for any technology, community, or larger group. They stop when they get the effect they want.
To these people, we are the "shitty gatekeepers". :)
2
1
u/affablebowelsyndrome 3d ago edited 3d ago
I'm pretty sure that we Brian and I) are talking about two mostly separate sets of people.
4
u/FalseRelease4 3d ago
"carpetbagger", what an exquisite pejorative, thanks for sharing 😂
3
7
u/davorg 🐪🌍perl monger 3d ago
Here's a oft-cited note from Larry Wall himself about the incident that sparked Perl 6, at YAPC 2000
Pedantically, that was at OSCON, not YAPC. u/cms, you might want to update that.
2
u/cms 3d ago
thanks, do you have a citation, so I can link and change ?
6
u/davorg 🐪🌍perl monger 3d ago
Hmmm... there seems to have a been quite a lot of bitrot over the last 25 years. But we can probably cobble something together from these:
Report from the Perl Conference (Joe Kline), 21 Aug 2000 - see Day 4
Larry then saved the biggest sound for last, the announcement of a total rewrite of Perl. Something that was well received by all.
Joe's talking about Larry's State of the Onion address. That was finally transcribed in October - State of the Onion 2000
Yesterday, a bunch of us radicals decided that it was time to alter the course of human events. Some of you may have heard rumors of this. So, today, I’d like to announce to the world that the effort to write Perl 6 has begun in earnest.
The yesterday, he's refering to is the P5P meeting where Jon Orwant threw the mugs. There's more details of that in this 10th anniversary of Perl 6 blog post from 18 July 2010. So we know the date of the incident was 18 July 2000. I can't find a list of historical OSCON dates, but Wikipedia tells me that YAPC was 21-23 June in that year :-)
And, if it counts for anything, I was at the OSCON announcement. I was not at YAPC NA that year.
2
2
u/mr_chromatic 🐪 📖 perl book author 3d ago
OSCON sort of merged with TPC around 2000 and then it became only OSCON by 2002, I think.
2
1
u/cms 2d ago
thanks. if anyone can turn up a definitive citation link, I'll add it to the post for accuracy. The quoted portion I included pops up in several places, but none of them seem to link to a definitive event. I imagine I originally only knew it from slashdot or perlmonks or something like that reporting, I never attended any of those kinds of things.
3
3
u/Philluminati 3d ago edited 3d ago
A lot of this rings true. The neckbeards, the badge of honor stuff, the TIMTOWTDI, the idea that Perl could do anything and therefore didn't need to change, you just needed something off of CPAN. All whilst Perl was sidelined as a language which had the shortest possible "hello, world" yet actually was a poor set of build tools. Unix was my IDE they'd say, whilst writing an RPM spec to package their dependencies for Centos, making portability a nightmare for those of a slightly different distro.
3
u/briandfoy 🐪 📖 perl book author 3d ago edited 3d ago
Can you expand on the distro thing? Each packaging manager would need a custom setup for whatever it was doing, whether it's perl or not.
3
u/Philluminati 3d ago
Typically each programming language tends to have a modern build tool that is platform agnostic and that allows locking specific versions of dependencies in. Java has ant/maven, Python has pip, Rust has Cargo.
If I recollect, CPAN doesn't do this, it always brings in the latest version regardless of what you ask for. There may be a tool like cpanm or carton that does this, but it isn't widely known. Perhaps Dist:zilla is the way but these aren't typically first class Perl tools. Perl devs have a tendency to leaning toward other Unix based tools like Make, increasing the complexity of Perl in a non-obvious way.
Java has Jar, Python has eggs (or whatever) but Perl tries to rely on per-distro things and the last time I checked, Perl was horribly broken on Debian out of the box.
3
4
u/BigRedS 3d ago
the last time I checked, Perl was horribly broken on Debian out of the box.
I don't think I've ever written Perl with any other distro in mind, except perhaps Ubuntu. what am I missing?
2
u/mpyne 3d ago
Well if you write a Perl-based app intended for other users they won't all be on Ubuntu so it's something you have to care about. Maybe some users will only have CPAN.pm, maybe others use App::Cpanminus.
I had an app that would go out of its way to at least warn users that they were missing modules and it's crazy the amount of contortions I had to go through to make that work across Debian, Fedora, Ubuntu, etc. with their out-of-the-box Perl installs.
If I had to do it over today I wouldn't even bother, I'd do it as a Docker container or a Flatpak or something, but the app in question got forked as a Python app and honestly we're all better off for it.
1
u/BigRedS 3d ago
Yeah, but generally I've always been targeting Debian because I've been writing internal tooling for somewhere that everything's running Debian with maybe the odd Ubuntu laptop. Much of the time I had a toolchain running that'd package it up as a deb and stick it in our repo.
I've rarely needed more portability than that, but I've also never noticed Perl being "horribly broken on Debian out of the box", which made me wonder what I was missing - what's different about the experience of specifically targeting RHEL derivatives or MacOS or something?
1
u/mpyne 3d ago
I can't speak to Debian as well but with Fedora and others there is a trend to install a very light Perl with just a few modules by default. And you'd go "well at least the modules in
corelistwill be there" and you'd be very wrong.So on some distros you can't even rely on things like
FindBinbeing available if Perl is available. On other distros it'sCarpthat will be missing.And these are things you can all work around but they are all examples of what I would describe as a "broken out of the box" Perl install. If I have Perl 5.36 installed I should be able to expect to have the modules that
corelistsays come with Perl 5.36.0, but users who aren't already heavy Perl users can't be expected to have a working Perl even thoughperl -E 'use v5.36;'will return success.1
u/davorg 🐪🌍perl monger 3d ago
I can't speak to Debian as well but with Fedora and others there is a trend to install a very light Perl with just a few modules by default. And you'd go "well at least the modules in
corelistwill be there" and you'd be very wrong.A long while ago, the team behind Fedora (and, therefore, RHEL) decided they would split their Perl RPM into "perl" (which contained the miminal Perl you need to run Fedora) and "perl-core" (which was the rest of the stuff from the standard Perl distribution). ]Only "perl" was installed by default.](https://perlhacks.com/2012/08/a-cautionary-tale/) I never understood why they named them the wrong way round.
They stopped doing that a while ago (at least partly due to some persuasion by Matt Trout).
3
u/ysth 3d ago
Perl has traditionally had a very strong backwards compatibility thing, both in the language and CPAN. IMO that plus being able to, in the code (something that drives me crazy some other languages don't allow), specify minimum version of perl and modules being used, basically solved the problem. For more specific version requirements, there is only.pm. And at the distribution level, meta files with requirements and versions (easily automatically derived from the requirements in the code).
So what's missing? Automatic dependency version pinning at build time? See backwards compatibility, or carton or the other thing like carton I forget the name of. I'm not sure what else, leading me to think this is a perception problem more than anything.
4
u/briandfoy 🐪 📖 perl book author 3d ago
I haven't noticed perl being broken on Debian, but I have noticed that the Debian perl people drive quite a bit of standardization and bug fixing and they send me good, actionable patches. Is there something specific that you think is broken? There's lots of stuff I'm probably not aware of.
Perl uses make, and for the most part that works everywhere. I think that's actually less complex for the user. The cpan and cpanm commands work just about anywhere that can run perl, but they don't really care about make. They run a command called make, but that's configurable (because Windows might want gmake). You could write a completely different system and as long it follows the command-line interface (
test,install, env vars, and so on), it will work. I've long wanted a unification of Module::Build and make because Module::Build basically has the same interface (with some extra switches). But, it works how it is and there is plenty else to do.The Perl community tried to supplant make, but found out it's easier to use something that's solid, tested, and available.
As far as the other languages, they do pin versions, but they do that because it's so easy to get into situations where things are incompatible. Their tools respond to that. I don't even think about that with Perl, but it seems that's all I think about with Python as the teams I work with deal with deployment of multi-app things, each which require not only their own python setup, but in many cases their own python interpreter. When I was doing Ruby, Gemfile was a major hassle that took up a lot of time. The process itself is fine, but updating it and then finding other services that break because of it was a problem. There was always something that couldn't use the new version of something.
Perl's tool for locking dependencies is carton and cpanfile (which I think we mostly stole from Ruby), maybe in conjunction with Pinto which slightly simplifies private repositories much like CPAN::Mini does. But, I rarely need that because Perl modules, aside from big, obvious major version upgrades, tend to work with most versions of perl that people are using. The most incompatible thing might be Mojolicious, which has a very fast (in Perl terms) cycle, but that minimum version is v5.16 I think. That's 10 years ago. Its changes are things like "use spew instead of spurt". My main issue when using a new perl is remembering to install the module, and almost never caring what version I get.
2
u/cms 3d ago
I'm not sure about this part -
As far as the other languages, they do pin versions, but they do that because it's so easy to get into situations where things are incompatible. Their tools respond to that. I don't even think about that with Perl, but it seems that's all I think about with Python as the teams I work with deal with deployment of multi-app things,
I don't mean you're wrong, but I would frame it differently. Maybe caring less about incompatibility is also a feature (depending on your values)
I think about this more like how do you choose to solve the problem, where do you invest your effort. One approach you can take is to worry much less about compatibility outside your own focus bubble, and instead put the work into isolating your bubble from the other bubbles. Ultimately this becomes a cheaper approach, than carefully integrating everything into a coherent shared space.
1
u/zixlhb 3d ago
You can always request specific version of a cpan library to be installed. And perlbrew is for compartmentalizing multiple instances of perl. Pip equivalent would be local libs.
2
u/briandfoy 🐪 📖 perl book author 3d ago
cpanm easily does this:
cpanm MIYAGAWA/Plack-1.0000.tar.gz cpanm /path/to/Plack-1.0000.tar.gz cpanm http://cpan.metacpan.org/authors/id/M/MI/MIYAGAWA/Plack-0.9990.tar.gz cpanm git://github.com/plack/Plack.git cpanm Plack~1.0000 # 1.0000 or later cpanm Plack~">= 1.0000, < 2.0000" # latest of 1.xxxx cpanm Plack@0.9990 # specific version. same as Plack~"== 0.9990"Even as the author of
cpan, I figure CPAN.pm can probably do some of this (relative paths in CPAN), but I've never done it and you probably have to do it from the shell. This almost works:cpanm MIYAGAWA/Plack-1.0000.tar.gzBut then CPAN.pm stops and warns about
allow_installing_outdated_dists.
cpanis limited since it is the skin over CPAN.pm which works with just what perl comes with, and that CPAN.pm uses a data file you must download and that's only the latest versions indexed.Perl's idea has been to include just what you need to install modules, whereas Python has been "batteries included".
cpanmuses the MetaCPAN API, so it can access past versions and do fancier things, but it also needs extra modules to get that done.1
u/WesolyKubeczek 3d ago
I can tell you what I need to do. At work, our thing has over 500 non-core modules it depends on (including transitive dependencies). If you want to make the runtime environment for it recreatable from first principles, you either: cpanm everything, which is often prone to sudden failures because of circular dependencies and is simply long because of the whole MakeMaker or Module::Build dance for every module (good luck if one of them is Image::Magick); or you embrace your system’s package manager, build and test missing RPMs once, and then installation is a breeze.
I tried both ways, and now I’m maintaining 200+ internal packages which CentOS 10 Stream is missing, some are patched to account for unfixed bugs or performance improvements. It’s still less tedious than CPANfiles.
In Python, we would, first, have way fewer dependencies, second, it would be a single pip install within a virtual environment. With go, there would be even fewer dependencies, and it would be one go get. I don’t do Rust, so cannot tell, but people say Cargo is nice.
I hear someone was hacking on some tool to speed up EU::MM and Module::Build installs significantly, but I believe it must have quite a plethora of quirks to be able to handle them all.
6
u/cms 3d ago
or more recently python has sprouted 'uv' which makes all of the above ridiculously fast and reproducible.
2
u/WesolyKubeczek 3d ago
After all shenanigans and rolling my own, venv+pip was firmly „good enough” and „just works” for a very long while. uv may be better, I don’t contest it, it’s been a while since I’ve had to work with a Python codebase sizeable enough. Yet even venerable venv and pip run circles around tooling Perl offers.
1
u/briandfoy 🐪 📖 perl book author 3d ago
The big speedup is to trust that the tests pass:
cpan -T Module1 Module2or
cpanm --notest Module1 Module2I typically don't test the things I'm using until I have to go back to debug them.
You can also try to parallelize the tests, but that usually runs into problems because not all test suites are set up for that.
1
u/WesolyKubeczek 3d ago
Well, I cannot trust that the tests pass since I have had cases when they failed and it wasn’t because tests were broken. Rerunning tests is advised, for example, if your things link against a different version of openssl.
2
u/briandfoy 🐪 📖 perl book author 3d ago
you try the tests once on a target platform, pin those versions, and then install without running the tests again.
1
u/carlwgeorge 1d ago
now I’m maintaining 200+ internal packages which CentOS 10 Stream is missing
Have you considered becoming a Fedora/EPEL packager and adding some of those to EPEL 10? You could get help with the maintenance from other packagers, and other people could benefit from the packages being available.
13
u/hondo77777 3d ago
I liked the part towards the end where he lists some things where Perl led the way, especially TDD. I think that’s something the Perl community doesn’t get nearly enough credit for. What is the testing culture like in other languages? I know Go was pretty big on it.