[HN Gopher] Perl is still relevant
___________________________________________________________________
Perl is still relevant
Author : mooreds
Score : 41 points
Date : 2022-07-10 20:36 UTC (2 hours ago)
(HTM) web link (stackoverflow.blog)
(TXT) w3m dump (stackoverflow.blog)
| 4oo4 wrote:
| 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.
| forgotmypw17 wrote:
| 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.
| 4oo4 wrote:
| 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?
| tyingq wrote:
| 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.
| xonix wrote:
| 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
| tyingq wrote:
| 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.
| bluedino wrote:
| 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...
| whartung wrote:
| > 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.
| ajsnigrutin wrote:
| 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.
| lordofgibbons wrote:
| 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.
| ajsnigrutin wrote:
| 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.
| jamespwilliams wrote:
| > 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.
| forgotmypw17 wrote:
| 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.
| waynecochran wrote:
| 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.
| [deleted]
| antiquark wrote:
| Or maybe it's not.
| d_e_solomon wrote:
| 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.
| GuB-42 wrote:
| 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.
| calvinmorrison wrote:
| 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.
| d_e_solomon wrote:
| That's good feedback. I'll have to give another go.
| alfiedotwtf wrote:
| 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
| phendrenad2 wrote:
| 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.
| x86x87 wrote:
| have you ever seen a linux box without perl? yeah.
|
| 6% of git is perl! perl is everywhere!
| mmcclimon wrote:
| 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.
| formerly_proven wrote:
| git-gui/gitk
|
| ... wait those are actually Tcl.
| krallja wrote:
| 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.
| x86x87 wrote:
| 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.
| WJW wrote:
| > 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.
| ascar wrote:
| 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.
| corytheboyd wrote:
| 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
| systems_glitch wrote:
| Yup, one of the big reasons I still use it. Basically every
| Perl module is also in OpenBSD's binary packages, too.
| darrenf wrote:
| 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...
| forgotmypw17 wrote:
| 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.
| endemic wrote:
| > why should I pick perl instead of Python or Ruby?
|
| Nostalgia, maybe.
| damagednoob wrote:
| 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#.
| ainar-g wrote:
| 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.
| waynecochran wrote:
| 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.
| mmcclimon wrote:
| 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.
| gerikson wrote:
| I believe Perl is integral to the OpenBSD package system.
| giantrobot wrote:
| 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
| goldenkey wrote:
| 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..
| dang wrote:
| Related:
|
| _Ask HN: Is perl still relevant today?_ -
| https://news.ycombinator.com/item?id=11406046 - April 2016 (4
| comments)
| newaccount2021 wrote:
| mmcclimon wrote:
| Perl may or may not be relevant in 2022 (it's certainly relevant
| to _me_ ), but this article does not do a great job at explaining
| Perl's merits. The example code, in particular, is certainly not
| what I'd expect to see in a modern Perl shop. They don't use
| warnings or strict, which the author cites as a benefit of Perl
| over Python, and which is the bare minimum for maintainable perl
| these days. The examples also use CGI.pm, which was removed from
| the core Perl distribution as of perl 5.22, which was released in
| June 2015! (Nowadays you'd use a framework for that; there are
| lots to choose from.)
|
| 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.
| dilan-dio4 wrote:
| avgcorrection wrote:
| 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.
| ForHackernews wrote:
| > 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...
| kouh wrote:
| 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.
| lcuff wrote:
| 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.
| orev wrote:
| 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).
| tyingq wrote:
| From the post: $id = $q->param('id'); $stmt
| = "select envip,mailfile,headers,subject,size,fromid,toid,date
| from quamail where id = $id";
|
| Yikes. His claimed expertise is _" Protect your e-mail server
| from ransomware attacks"_ too.
| classichasclass wrote:
| Hi, Bobby Tables!
| [deleted]
| azinman2 wrote:
| 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?
| tyingq wrote:
| Yes, it will interpolate. The DBI package he's using does
| support parameter bindings with a ? character. He's just
| doing it wrong.
| AnimalMuppet wrote:
| No, Perl strings are interpolated at creation.
| Areading314 wrote:
| This is a classic SQL injection bug/security flaw
| Areading314 wrote:
| 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....
___________________________________________________________________
(page generated 2022-07-10 23:02 UTC)