Perl is still relevant(stackoverflow.blog)
stackoverflow.blog
Perl is still relevant
https://stackoverflow.blog/2022/07/06/why-perl-is-still-relevant-in-2022/
75 comments
> you should probably pick a language with a future, and that language is probably not Perl.
A combination of Bash (sed, awk, grep) and Python (string manipulation) eliminates any need for Perl.
A combination of Bash (sed, awk, grep) and Python (string manipulation) eliminates any need for Perl.
Perl certainly suffers under 'TMTOWTDI' with libraries. Go to CPAN, ask a friend, hit stackoverflow, you're gonna find something, but like with PHP, there's probably a bunch of libraries you shouldn't be using or have been superseded
> you should probably pick a language with a future, and that language is probably not Perl.
Perl may not have a future, but being the language in which you can summon Cthulhu with the fewest characters, it has an eternal, undying past.
Perl may not have a future, but being the language in which you can summon Cthulhu with the fewest characters, it has an eternal, undying past.
From the post:
$id = $q->param('id');
$stmt = "select envip,mailfile,headers,subject,size,fromid,toid,date from quamail where id = $id";
Hi, Bobby Tables!
I’m not terribly familiar with Perl. Will that interpolate at string creation, or is that just text in a string that the db driver will later do parameter bindings with?
No, Perl strings are interpolated at creation.
This is a classic SQL injection bug/security flaw
Ironic since I always thought one of the coolest features in perl was taint analysis, which allows keeping track of all unparsed user input:
https://www.geeksforgeeks.org/perl-taint-method/#:~:text=Tai....
https://www.geeksforgeeks.org/perl-taint-method/#:~:text=Tai....
Yes, it will interpolate. The DBI package he's using does support parameter bindings with a ? character. He's just doing it wrong.
[deleted]
What I imagine I will use Perl for is as a replacement for Sed, Awk, and all those little tools that are simple but either have annoying differences or are gimped in some way or another. I don’t like SSHing into another “box” and being at the mercy of that things `PATH`, but if most of those boxes have Perl installed then at least I can bring some utility scripts with me.
But beyond that? I think not.
As an application programmer Perl will never be a daily tool for me. So it gets relegated to that once in a while toolshed. But then that Tim Toady slogan kind of might get in the way: I don’t want to google for all kinds of “creative” ways to just get from A to B. Because I will surely be in that annoyed, I just wanna get this thing done kind of mood (is “in anger” the right phrase?).
> We can easily invoke a Perl daemon to avoid spending hours working on C and avoid several security flaws.
> […]
> In today’s event-loop-centric asynchronous world of JavaScript, node.js, and TypeScript, Perl offers a very straight-forward code flow, and Perl code offers simplicity and control.
In a few paragraphs the author went from some ’90s looking argument (you don’t even have to touch C) to mentioning baby’s first exotic synchronous programming encounter. I almost got a whiplash.
But beyond that? I think not.
As an application programmer Perl will never be a daily tool for me. So it gets relegated to that once in a while toolshed. But then that Tim Toady slogan kind of might get in the way: I don’t want to google for all kinds of “creative” ways to just get from A to B. Because I will surely be in that annoyed, I just wanna get this thing done kind of mood (is “in anger” the right phrase?).
> We can easily invoke a Perl daemon to avoid spending hours working on C and avoid several security flaws.
> […]
> In today’s event-loop-centric asynchronous world of JavaScript, node.js, and TypeScript, Perl offers a very straight-forward code flow, and Perl code offers simplicity and control.
In a few paragraphs the author went from some ’90s looking argument (you don’t even have to touch C) to mentioning baby’s first exotic synchronous programming encounter. I almost got a whiplash.
> is “in anger” the right phrase?
Probably not quite. You don't have to be angry to use a tool "in anger"
Something used in anger would be "used for its intended purpose, or used for real rather than in tests"[0]. In this context, perhaps running Perl on live production servers.
[0] https://english.stackexchange.com/questions/30939/is-used-in...
Probably not quite. You don't have to be angry to use a tool "in anger"
Something used in anger would be "used for its intended purpose, or used for real rather than in tests"[0]. In this context, perhaps running Perl on live production servers.
[0] https://english.stackexchange.com/questions/30939/is-used-in...
Wow thanks for that, you just shone a light in a dark corner of my mind.
I am not a native speaker, although I have a decent level in english (enough that some native english speakers thought I was on multiple occasions, which boggles my mind).
So, somehow I always had an uncanny feeling with "in anger": much to my surprise I intuitively wanted to use it the "proper" way regularly but somehow always refrained from it because rationally I thought it really carried the literal "angry" weight, even though it just didn't feel true.
Idioms really can turn out odd.
I am not a native speaker, although I have a decent level in english (enough that some native english speakers thought I was on multiple occasions, which boggles my mind).
So, somehow I always had an uncanny feeling with "in anger": much to my surprise I intuitively wanted to use it the "proper" way regularly but somehow always refrained from it because rationally I thought it really carried the literal "angry" weight, even though it just didn't feel true.
Idioms really can turn out odd.
The title doesn't really match what I expected from the article. I was expecting use cases where Perl just excels or is a hard to remove part of a critical work flow that needs active Perl development.
I know why I would pick Perl over bash. But why should I pick Perl instead of Python or Ruby? Ruby is a natural choice for all the things he mentioned too. That's the question I would've liked answers to.
I know why I would pick Perl over bash. But why should I pick Perl instead of Python or Ruby? Ruby is a natural choice for all the things he mentioned too. That's the question I would've liked answers to.
One potential answer is Perl might be installed in more places by default, so portability. Things like MacOS have all three installed, but some random Linux environment might not. It's a bit of a stretch, but you asked hah
Actually Apple announced a deprecation in 2019, so in some ways it’s surprising to still find Perl installed by default in macOS. From the Catalina release notes[0]:
Scripting Language Runtimes Deprecations
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.
[0] https://developer.apple.com/documentation/macos-release-note...
Scripting Language Runtimes Deprecations
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.
[0] https://developer.apple.com/documentation/macos-release-note...
Oh that's actually wonderful news, system installed runtimes always trip up the less familiar when version managers are involved, which is basically every rails shop (rbenv or rvm)
Yup, one of the big reasons I still use it. Basically every Perl module is also in OpenBSD's binary packages, too.
I pick it because it is widely installed and does not require additional packages or configuration to be useful. And I like the syntax. I write "basic" no-frills Perl which I can read next month, and I can copy it to another machine and be sure it will work.
> why should I pick perl instead of Python or Ruby?
Nostalgia, maybe.
Nostalgia, maybe.
> Perl is not going away. That ain’t gonna happen.
> It is still being used in CGI scripts. It is used in several sys admin tasks. > Perl is still alive and kicking.
I thought this was an article in favor of Perl, but when you write things like this in the conclusion you don't make your job easier... I agree though, there will be perl code around for decades, even just because some ancient systems were written in it and they haven't been replaced (yet). But at the same time, if I were a CTO at a company with 5-10 critical Perl scripts my first instict would not be to hire more Perl devs but to migrate away from that ASAP.
> It is still being used in CGI scripts. It is used in several sys admin tasks. > Perl is still alive and kicking.
I thought this was an article in favor of Perl, but when you write things like this in the conclusion you don't make your job easier... I agree though, there will be perl code around for decades, even just because some ancient systems were written in it and they haven't been replaced (yet). But at the same time, if I were a CTO at a company with 5-10 critical Perl scripts my first instict would not be to hire more Perl devs but to migrate away from that ASAP.
Their Perl examples are full of line noise and footguns. Just the string concat operator can be a source of problems because it was misplaced or forgotten. The qw() operator is also very confusing unless it's explicitly explained.
I don't hate on Perl, the first code I ever got paid to write was Perl. It's not a bad language. It's also not a good language. It's a nice glue language you can assume will exist on any random Unix-like machine you sit down at. Its nice in that it can replace a mess of bash/awk/sed scripts.
That being said I could not imagine starting a green field project today in Perl unless everyone on the team was a Perl monger. Even then I think there's much stronger options than Perl for most types of projects.
Edit: autocowrong typo
I don't hate on Perl, the first code I ever got paid to write was Perl. It's not a bad language. It's also not a good language. It's a nice glue language you can assume will exist on any random Unix-like machine you sit down at. Its nice in that it can replace a mess of bash/awk/sed scripts.
That being said I could not imagine starting a green field project today in Perl unless everyone on the team was a Perl monger. Even then I think there's much stronger options than Perl for most types of projects.
Edit: autocowrong typo
As some who dipped in to Perl 3 times, each a decade apart and therefore dealt with Perl 3, 4 and 5, it's annoying that now in version 6, the Perlites finally realize that they got the ridiculous way of using sigils wrong.... $foo[2] is (formerly) an element of @foo. Also the joyous talk of brevity (think $_) is nauseating. Having to Google for the meaning of line noise is once, twice, three times a headache.
I acknowledge that every mind is different, and folks are drawn to different languages. I've met engineers who hated syntax coloring. But for the mind behind my own eyes, I love Ruby, hate Perl.
I acknowledge that every mind is different, and folks are drawn to different languages. I've met engineers who hated syntax coloring. But for the mind behind my own eyes, I love Ruby, hate Perl.
There is no Perl 6. They finally woke up to the fact that the Perl 6 never-ending development was hurting the language, and now it’s a completely different project (Raku).
That is incorrect, for several reasons.
If you consider "never-ending development" until the first release, then Perl 6 ended development in 2015 when it was released.
If you consider "never-ending development" biologically, then it just means that the language is alive. Which it is, and Perl as well for that matter.
If you consider the language "Perl", then it should continue to be noted that for Larry Wall, Perl 6 (now Raku) still IS the next version of Perl. It just has a different name now.
If you consider "never-ending development" until the first release, then Perl 6 ended development in 2015 when it was released.
If you consider "never-ending development" biologically, then it just means that the language is alive. Which it is, and Perl as well for that matter.
If you consider the language "Perl", then it should continue to be noted that for Larry Wall, Perl 6 (now Raku) still IS the next version of Perl. It just has a different name now.
I always want to like Perl, but I struggle to find use cases that aren't better served by Python or Go on the web side; or just straight bash on the sysadmin side.
Perl is really nice when you are passing a lot of data around compared to bash. Enough struggling with parsing and escaping and bash arrays and you'll be better fit for perl very quickly.
Perl is also really fast to prototype with, with a lot of nice helpers for scripts like while(<>) { say $_; }, make writing oneliners/short scripts easy.
I find Perl is a good fit above bash.
Perl is also really fast to prototype with, with a lot of nice helpers for scripts like while(<>) { say $_; }, make writing oneliners/short scripts easy.
I find Perl is a good fit above bash.
That's good feedback. I'll have to give another go.
> Perl is really nice when you are passing a lot of data around compared to bash
I know some might consider this heretical, but have you considered Powershell for these type of scripts?
I know some might consider this heretical, but have you considered Powershell for these type of scripts?
Perl has much less footguns than bash, it is also more powerful and faster.
No language I am aware of have more footguns than bash, with the exception of some other Unix shells.
But really, I really like Perl for throwaway scripts and one-liners. Because of its syntax, Python essentially can't do one-liners, and generally, Perl code is shorter and quicker to write assuming you are experienced in both languages.
But I agree that readability is terrible unless you are really careful. When my Perl scripts get a bit too big, slow, and less "throwaway", I tend to rewrite them in another language. Often C or C++ because I know these well but I guess that Go can work too.
Python has some great features, it is simple and code is naturally readable, but for me it sits on an uncomfortable spot: not permissive enough for quick, throwaway code, and too permissive and slow for larger, maintained projects.
No language I am aware of have more footguns than bash, with the exception of some other Unix shells.
But really, I really like Perl for throwaway scripts and one-liners. Because of its syntax, Python essentially can't do one-liners, and generally, Perl code is shorter and quicker to write assuming you are experienced in both languages.
But I agree that readability is terrible unless you are really careful. When my Perl scripts get a bit too big, slow, and less "throwaway", I tend to rewrite them in another language. Often C or C++ because I know these well but I guess that Go can work too.
Python has some great features, it is simple and code is naturally readable, but for me it sits on an uncomfortable spot: not permissive enough for quick, throwaway code, and too permissive and slow for larger, maintained projects.
Perl is great.
The lack of stackoverflow questions probably has something to do with code written 10, 15, even 20 years ago still working, without a need to constantly rewrite it, because language writers change the language every two versions, or distro mainatainers decide to deprecate the language.
The lack of stackoverflow questions probably has something to do with code written 10, 15, even 20 years ago still working, without a need to constantly rewrite it, because language writers change the language every two versions, or distro mainatainers decide to deprecate the language.
That's certainly one rosy way to describe it. Another more realistic explanation one is that it's just an awful language to work in and people aren't writing new software in it.
I'm speaking as someone who had the misfortune of maintaining one of those 15 year old legacy Perl systems.
After finally rewriting the Perl based systems in Go, our outages went to nearly zero, and we could handle multiple times more traffic.
Engineer on-boarding was also easier because they could understand what was going on by just being able to read the code. A novel concept, I know.. /s But that was impossible to do with the Perl based services.
I'm speaking as someone who had the misfortune of maintaining one of those 15 year old legacy Perl systems.
After finally rewriting the Perl based systems in Go, our outages went to nearly zero, and we could handle multiple times more traffic.
Engineer on-boarding was also easier because they could understand what was going on by just being able to read the code. A novel concept, I know.. /s But that was impossible to do with the Perl based services.
Of course "new guys" will learn the "language of the week", and "old bearded sysadmins" will continue using perl, but still.. i have stuff literally written a deacade+ ago, still working without issues, and i have stuff written in ruby, rewritten to python (2.6?), fixed for 2.7, and rewritten for python3, that I abondoned ~python 3.3, and rewritten in perl, just to be able to forget about it.
> i have stuff literally written a deacade+ ago, still working without issues
Maybe this works if you run your Perl in the exact same environment the whole time, or if you're writing stuff on a very small scale and don't need to use many CPAN modules.
But for large applications, you'll be using CPAN modules heavily. And you'll need to run your Perl in new environments - if for no other reason, because you'll need to move to new operating system versions to pick up security updates.
That's where the problems start. If you're using a reasonable number of CPAN modules, this inevitably breaks some of them. And because the Perl ecosystem is essentially dead, those third-party modules are usually abandoned.
Maybe this works if you run your Perl in the exact same environment the whole time, or if you're writing stuff on a very small scale and don't need to use many CPAN modules.
But for large applications, you'll be using CPAN modules heavily. And you'll need to run your Perl in new environments - if for no other reason, because you'll need to move to new operating system versions to pick up security updates.
That's where the problems start. If you're using a reasonable number of CPAN modules, this inevitably breaks some of them. And because the Perl ecosystem is essentially dead, those third-party modules are usually abandoned.
Related:
Ask HN: Is perl still relevant today? - https://news.ycombinator.com/item?id=11406046 - April 2016 (4 comments)
Ask HN: Is perl still relevant today? - https://news.ycombinator.com/item?id=11406046 - April 2016 (4 comments)
It's a okay article, but they really should have mentioned the Perl 7 initiative as well as the fact that Perl is still installed by default on OpenBSD and some other BSD and Linux-based OSes.
Is anything after Perl 5 relevant?
Perl <= 5 is the duct tape hold many corners of the Internet together.
I don't know anything significant after v 5.
The current version of perl is 5.36 (it's a really good perl). The language formerly known as Perl 6 is now called Raku. The "Perl 7 initiative" referred to in the grandparent is the idea that at some point, the 5.x series (i.e., the language you know as Perl) will accrue enough features and deprecate enough very old behavior that it'll get rebadged as Perl 7.
There's not a timeline for that right now, nor clear consensus on what exactly will be worth a version bump or how much backcompat between 5.x and 7.x there will be going forward. It's being actively discussed, though; the Perl Steering Committee (formed a couple of years ago) meets weekly, and discussion on p5p (the language development mailing list) is still fairly active, though admittedly much less so than in years gone by.
There's not a timeline for that right now, nor clear consensus on what exactly will be worth a version bump or how much backcompat between 5.x and 7.x there will be going forward. It's being actively discussed, though; the Perl Steering Committee (formed a couple of years ago) meets weekly, and discussion on p5p (the language development mailing list) is still fairly active, though admittedly much less so than in years gone by.
I believe Perl is integral to the OpenBSD package system.
Why is this charlatan of an author showing off poorly written scripts they wrote 10 years ago that are riddled with SQL injection vulnerabilities?
That kind of goes against the point of Perl being modern..
That kind of goes against the point of Perl being modern..
I still like Perl as a single-developer language, because of its freedom of expression. However, this is also why it is not that a great language for teams. As I see it, the decline of Perl isn't so much for the language being "bad", but for how the industry has changed, especially when it comes to how projects are generally handled.
When at some point I decided to learn AWK better, I was surprised to find that it had some very Perl-ish features, like `print` is the same as `print $0` or `if(/abc/){}` as shorthand for `if($0 ~ /abc/){}`, etc. Later I learned that Perl was designed as an AWK-on-steroids by Larry Wall.
No doubt Perl is much more powerful than AWK. But from other side it’s astonishing that such succinct and clear language as AWK was turned into a monstrosity called Perl.
Therefore, for me when it goes to text processing/manipulation I prefer AWK much better than Perl. Cleaner syntax, better portability, absolute minimalism. Now, thanks to GoAWK [0] CSV-processing with AWK is a piece of cake too.
I personally see no reason nowadays for me to write any Perl code, but I’m totally fine to use the software written in it.
[0] https://news.ycombinator.com/item?id=31350550
No doubt Perl is much more powerful than AWK. But from other side it’s astonishing that such succinct and clear language as AWK was turned into a monstrosity called Perl.
Therefore, for me when it goes to text processing/manipulation I prefer AWK much better than Perl. Cleaner syntax, better portability, absolute minimalism. Now, thanks to GoAWK [0] CSV-processing with AWK is a piece of cake too.
I personally see no reason nowadays for me to write any Perl code, but I’m totally fine to use the software written in it.
[0] https://news.ycombinator.com/item?id=31350550
He did take some inspiration from AWK, but Perl wasn't meant to be just an AWK replacement. For me, in the time when it first came out it was really handy, as you had access to most of the C stdlib without having to write C. I had a job in the 90's writing software that was a protocol hub of sorts, and Perl was really nice for testing since I could use tcp and udp sockets, interact with serial ports, etc. There wasn't really anything comparable at the time.
As much as I love Unix I am terrible at Perl. Anyone know any good resources for learning Perl 5?
I seem to stumble quite a bit with CPAN in comparison to pip or npm. Correct me if I'm wrong, but I think that's because it's not a true package manager like those, and more of just a module downloader that's not as stateful?
CPAN pains I think are a huge reason why I haven't learned it better, also I think Perl can vary quite a bit with readability compared with other languages.
You can write nice looking Perl like those examples but I've also seen things with extremely dense and terse syntax that I can't even begin to walk through. To take an extreme example, RSA in 3 lines of Perl. I have always been curious how that is actual working code.
I seem to stumble quite a bit with CPAN in comparison to pip or npm. Correct me if I'm wrong, but I think that's because it's not a true package manager like those, and more of just a module downloader that's not as stateful?
CPAN pains I think are a huge reason why I haven't learned it better, also I think Perl can vary quite a bit with readability compared with other languages.
You can write nice looking Perl like those examples but I've also seen things with extremely dense and terse syntax that I can't even begin to walk through. To take an extreme example, RSA in 3 lines of Perl. I have always been curious how that is actual working code.
There's cpanminus...it's pretty popular: https://metacpan.org/dist/App-cpanminus/view/bin/cpanm
It downloads dependencies automatically and does a reasonable job with --uninstall, which is probably your main complaints.
It downloads dependencies automatically and does a reasonable job with --uninstall, which is probably your main complaints.
O'Reilly's "Learning Perl" is definitely the best way to get from zero to intermediate imho.
For cpan stuff, carton works perfectly for me (it's like bundler for Perl). I also prefer plenv for specifying the specific and most up to date version of Perl.
I don't use CPAN. If I need something I don't want to write myself, I use the command line.
To use RSA as an example, instead of trying to use a PGP module from CPAN, I use the gpg command-line program, write its output to a file, and use that.
It's not as graceful, but it is also highly compatible with just OS packages.
To use RSA as an example, instead of trying to use a PGP module from CPAN, I use the gpg command-line program, write its output to a file, and use that.
It's not as graceful, but it is also highly compatible with just OS packages.
I bet you get better performance that way too. That kinda confirms my suspicions that Perl modules are awful to work with, though I'll admit I'm an idiot about the Perl ecosystem so there may be better module tools I don't know about.
What makes you choose Perl over bash/sh then, if it's working as a "glue" between actual binaries? I imagine the text processing things it excels at?
What makes you choose Perl over bash/sh then, if it's working as a "glue" between actual binaries? I imagine the text processing things it excels at?
I would choose bash, but the syntax is just too awkward for me.
I feel comfortable with parentheses, curly braces, freeform whitespace, etc., if/else, do/while, foreach, etc., and that's how I write my Perl.
I sometimes call it "PHP style Perl", because most of the code i write can be copied and pasted almost verbatim between PHP and Perl, and I use this to my advantage.
I don't use PHP a lot, but I do find it one of the most convenient ways to duct-tape things to a web server.
On the whole, I've settled on a strategy of writing most code in such a way that it could have been written (with perfect foresight of the future) 20 years and go and have worked the whole time.
I think of it as exploiting the Lindy Effect to my advantage. :)
I feel comfortable with parentheses, curly braces, freeform whitespace, etc., if/else, do/while, foreach, etc., and that's how I write my Perl.
I sometimes call it "PHP style Perl", because most of the code i write can be copied and pasted almost verbatim between PHP and Perl, and I use this to my advantage.
I don't use PHP a lot, but I do find it one of the most convenient ways to duct-tape things to a web server.
On the whole, I've settled on a strategy of writing most code in such a way that it could have been written (with perfect foresight of the future) 20 years and go and have worked the whole time.
I think of it as exploiting the Lindy Effect to my advantage. :)
Not the person you’re responding to, but for me any time I have to perform any branching logic in a shell script I start reaching for Python or Perl.
I guess I'm being nitpicky but...
> Python is an out and out object-oriented paradigm.
Is this true? I thought it was considered 'multi-paradigm'. You could write a program without using a class for instance which is difficult (impossible?) in Java or C#.
> Python is an out and out object-oriented paradigm.
Is this true? I thought it was considered 'multi-paradigm'. You could write a program without using a class for instance which is difficult (impossible?) in Java or C#.
It seems true. Even fundamental data types, like ints, strings, etc. are "objects" in Python. Java has primitive types, like "int", that are not objects (It also has "object" equivalents that can be used for boxing: int primitive => Integer class.)
More on topic, I used to do a ton of perl in the late 90's through the early 2000's. Before PHP gained popularity, it was a simple way to write a web app (perl CGI.) I haven't touched it in over a decade now.
More on topic, I used to do a ton of perl in the late 90's through the early 2000's. Before PHP gained popularity, it was a simple way to write a web app (perl CGI.) I haven't touched it in over a decade now.
Perl is nice because most Linux distros come with it by default, and it's a more traditional scripting language than Bash. I just wish someone would combine Perl with Ruby syntax and somehow add that to the Linux standard base.
I love Perl because it prioritizes backwards compatibility, and I have some confidence that my scripts will run both a couple years from now and on older installs which have older versions. . . among many other reasons.
have you ever seen a linux box without perl? yeah.
6% of git is perl! perl is everywhere!
6% of git is perl! perl is everywhere!
Very little of git as used by most people is Perl these days; almost everything has been rewritten in C by now. A few things remain, but they're pretty niche: git-send-email, the git-cvs tools (!), git-svn, and git-fast-import (maintained in the contrib/ tree) look to be the only top-level perl things left, at a glance.
git-gui/gitk
... wait those are actually Tcl.
... wait those are actually Tcl.
I just booted a Gentoo rescue CD from the early 2000s and it didn’t have perl. It pretty much only had busybox and nano.
haha. fair. if you're going to use a specialized linux distro or use linux for a very targeted purpose (ie rescue CD) you might get away without perl. short of that it's in every mainstream distribution.
imho, the language didn't age as well as other popular multi-paradigm predecessors. I never got my head around their OO implementation, or handling of arguments.
Forget Perl.
I used to randomly do a thing or two in it because it seems like "there's a CPAN for that".
Once in a great, great while I'll have a script that's part of something that needs a change.
But I won't write it if I don't have to. Why would I? Python has too many advantages and also has all the libraries I could want. My co-workers know it, it's easy to read and write...
I used to randomly do a thing or two in it because it seems like "there's a CPAN for that".
Once in a great, great while I'll have a script that's part of something that needs a change.
But I won't write it if I don't have to. Why would I? Python has too many advantages and also has all the libraries I could want. My co-workers know it, it's easy to read and write...
> I used to randomly do a thing or two in it because it seems like "there's a CPAN for that".
Yea, historically, every time I followed that siren song of "there's a CPAN for that", it inevitably led to ruin and tears. I found my CPAN experience to be buggy, fiddly, and overall unsuccessful. It's what drove me away from the eco-system entirely.
Yea, historically, every time I followed that siren song of "there's a CPAN for that", it inevitably led to ruin and tears. I found my CPAN experience to be buggy, fiddly, and overall unsuccessful. It's what drove me away from the eco-system entirely.
Perl for me my goto replacement for non-trivial bash scripts. Perl is a practical extraction and report language as well -- need to ingest some text, do some pattern matching, transmorgify, and output a CSV -- Perl excels at that. BTW, I am referring to Perl 5 -- anything after that seems esoteric BS.
Or maybe it's not.
Perl is not going away because almost every Linux dstro comes with Perl pre-installed. And Perl is pre-installed because it's a dependency of many old tools. autoconf, automake, ad-hoc build scripts and test suites of many old (established) packages require Perl.
The fact that Perl is available on most popular OS natively is a huge plus. I was looking to write a cross-platform installation script recently and that alone almost swayed me to avoid a pure Bash implementation.
I love that Perl exists.
It's one of those things that, if days had 72 hours and the human average lifespan was 300 years, I would love to master.
Unfortunately, that isn't the case.
It's one of those things that, if days had 72 hours and the human average lifespan was 300 years, I would love to master.
Unfortunately, that isn't the case.
i really appreciate zx[1] for putting the scripting into javascript. just a couple super small tweaks/libraries & js becomes much simpler to script.
there's also a deno port[2].
[1] https://github.com/google/zx
[2] https://deno.land/x/[email protected]
there's also a deno port[2].
[1] https://github.com/google/zx
[2] https://deno.land/x/[email protected]
For devops, I'll always start with a bash... but anything more complicated than a few commands and subroutines, I default to my beloved Perl <3
I find Perl most valuable for regex from the console but everything else is python.
[deleted]
the perl community is small(er) but I would argue more active and effective than in recent years
every perl library I make use of is updated regularly
perl itself is released regularly and just had a 5.36 release
perl won't be conquering much new territory, but it isn't going away either
every perl library I make use of is updated regularly
perl itself is released regularly and just had a 5.36 release
perl won't be conquering much new territory, but it isn't going away either
Many of the things the author cites are good about Perl are, in fact, good about Perl. But if you're writing new software in 2022, you should probably pick a language with a future, and that language is probably not Perl.