Last year I needed to do a small project to run on a web server with only Apache available. Rather than go to the pain of requesting some new web stack installed I wrote a single CGI script in perl 5 - just as I used to many years ago.
I did it the old-school way with no fancy framework, just CGI.pm. I made fun of myself to my collegues saying it was great to live in the 90s again. But actually, after a few hours coding it became clear that we haven't progressed very far.
It was a single script and it just worked. It was also much more fun than persuading a web framework to do what I wanted because I was actually programming and not configuring.
It's a similar experience in Java-land when you throw out the frameworks and all the servlet container bullshit and just start up an embedded Jetty. It's easy, lightweight, fast, you can do anything you want without crapping out mountains of XML configuration, or layer upon layer upon layer of introspecting, byte-code engineering, dynamic code-rewriting-where-the-hell-did-THIS-code-come-from annotations. You have control, in the place where it matters - the source code. You can write end-to-end tests that developers will actually run, because they don't need to spin up JBoss for 5 minutes before they're ready to go.
Frameworks have got a lot to answer for; it's very rare that a large project actually gets to use the flexibility that a modern framework provides. Who the hell actually swaps out their ORM or their database for a different one in a production system? Sure, the lead architect was sold on the idea that they wouldn't be tied to a particular implementation, but when the shit hits the fan the business will deem it "too risky - find another solution".
Thus we advance to the third level of professional software development, the Sarcophagus model - wherein it's simply too risky to actually CHANGE any part of a (now-legacy) production system, but we CAN build a sarcophagus around the toxic core such that no more careers need be sacrificed to trying to maintain it. I have some great examples of this, but professionalism forbids me from relating them. Perhaps when I finally decide that keeping sheep on a remote island is preferable to being a software "engineer", I'll start writing about them.
So right. Just spin the damn jetty, put the postgre driver and off you go. Most of the infrastructure is done in a day or two, and if not enough you can always revisit it later. And it runs fast. So fast that it feels like dynamic language. And even with the modern apps, where most of the action is on the client (and the server is interface to the DB most of the time) you even don't need to restart your server that often.
I think that whoever says that Java is not good language for development either have seen only j2ee or never did looked around. (as a prime example the stupid bean convention and tools which operate on it)
I know my reason for not wanting to develop in Java is that since for the most part the speed difference doesn't matter for my needs, it boils down to how easily I can transcribe/translate my concepts into code.
The conceptual impedance of Java is just higher for me. I think most of the code I write (the non-algorithm complex stuff) that boils down to stuff like "take the subset of the collection of orders with a total over 100, and sort by number of items." In Perl, that may be as simple as:
I think allowing me to express myself easily and succinctly like this saves time, reduces errors and allows me to concentrate my time and attention on the more complex portions of the code.
I also think succinctness (where idiomatic for the language, so it's not confusing) is useful in it's own right. The more of the current (or related) function and program state that's obvious on the screen when I'm coding, the less likely I am to have to break off from what I'm doing to go look up a detail I need.
Because `> 100` is missing from the condition? Other than an example of poor copy-pasting of code, how do you conclude that it is "[n]ot a great advert for Perl"?
For the record, this would be the code with missing part included:
It might lead someone to conclude that Perl users were slapdash in their approach and prone to tossing off untested code. Possibly unreasonably, possibly not.
More often than not, I am wondering just how much complexity one could spare themselves from if they would just use tomcat and postgres/mysql/some-nosql instead of a full-blown oracle-enterprise DB and a serious-business "application server" - both of which said applications are using maybe 10% the features of and basically never any of the really cool features that make them so expensive in licensing.
I know exactly what you mean. I banged out emacsformacosx.com in a weekend and wrote a real quick CGI program in Perl just so I didn't have to keep typing "make" or something while I was writing the site (since I was using Template::Toolkit). I fully intended to move it to "something good" once it was done--there's no way CGI can work on a site with more than 10 users, right?
Well, after 3 years it's still plain perl CGI. Every web request, forks, compiles the perl code, compiles the template code, stat()s over 3000 Emacs builds and then renders the page. There is no caching. It's wrong my almost every measure of modern web code design. And yet, it's still fast enough for the amount of traffic it gets.
Oh, and it's still hosted by a computer in my house over my cable modem. Yes, it's a niche-y site, but it turns out that niche-y sites can still do a lot with a little, even on today's web.
Fantastic "hey, perl is not dead" article, and read it just as I was hunkering down to do some AWS automation with perl.
What has always impressed me is the consistency and quality of the documentation of most CPAN modules. There's a huge group of people working at improving perl infrastructure and they don't get half the credit that they deserve!
Yeah, metacpan is a killer interface to CPAN. But it really comes down to the efforts of the individual module maintainers to create all of that great documentation.
It's still difficult to beat perl in a production Unix environment to fix a hot issue, especially if you know your way around regular expressions. When I hear comments like "now you have two problems", or "it's harder to read than to write", or references to the P in LAMP being Python or PHP, I chuckle to myself.
This illustrates the use of Perl in quick one-liners and helps understand why Perl isn't suitable for writing maintainable code. I've seen far too many cases of (and done it myself too often) assumptions like "there's no other tags ending in 'nk'" and "I can parse this XML/HTML content with simple regexps" in the quick & dirty code that is typical Perl (it works, let's use it...). This is where much of the productivity gains and "fun" comes from in the short term and where all the maintainability problems come from in the long term.
Evangelists will preach "modern Perl", good style and Moose to you, but these are half-baked, tacked-on solutions, they aren't fun and the overhead destroys the perceived advantages over other languages while not alleviating the massive disadvantages Perl has (performance, dynamic typing, lack of proper threading support...) over modern languages for medium to large size projects.
So, use if for one-off jobs and one-liners but don't get sucked into it for anything that intends to grow into a few 100 lines or more.
Disclaimer: I've used mostly Perl for ~15 years now and built a company with assorted technical debt, so this is biased on my personal hindsight. YMMV.
> This illustrates the use of Perl in quick one-liners and helps understand why Perl isn't suitable for writing maintainable code.
That's seems like a bit of a stretch to accept from a single anecdote.
> I've seen far too many cases of (and done it myself too often) assumptions like "there's no other tags ending in 'nk'" and "I can parse this XML/HTML content with simple regexps" in the quick & dirty code that is typical Perl (it works, let's use it...)
So you blame Perl for programmers making poor choices in how they parse their data?
> Evangelists will preach "modern Perl", good style and Moose to you, but these are half-baked, tacked-on solutions
How are they half-baked and tacked on?
> while not alleviating the massive disadvantages Perl has (performance, dynamic typing, lack of proper threading support...)
You mind supplying evidence for any of these? For some, dynamic typing is a feature. As for threads, I make heavy use of them every day, and while they have their quirks, they work quite well in some circumstances. Performance?
> So you blame Perl for programmers making poor choices in how they parse their data?
That wasn't a poor choice. I didn't propose "si.+?nk" as a general rule, and I would have used another method if there had been conflicting tags in the file.
I also take issue with the parent comment about perl not being usable for long scripts; that's nonsense. A comm framework I wrote in perl in '04 still sends payroll data for our 18k employees to the bank. It weighs in at around 400 lines, makes calls to gnupg, a database, has a scheduling engine that can parse cron entries, has support for EDI wrapping/unwrapping functions, logging, error alerting, other bells and whistles I'm forgetting right now.
There was nothing in the language that made this absurd or unsupportable.
> That wasn't a poor choice. I didn't propose "si.+?nk" as a general rule, and I would have used another method if there had been conflicting tags in the file.
I wasn't really speaking to any criticism of you in particular, but to the general statement about assumptions when using Perl.
I myself have used a regex to pull out well formed XML chunks and then re-parse them with a regex to build a hash out of the attributes of each chunk. It turns out it's 10x faster that any XML solution I could find (and there's quite a lot on CPAN!). The fact that it was a few hundred MB of XML and with a regex I could step my way through it probably had a lot to do with that...
I read through your perl posts and ended up at your summary article for perl features written in 2005. As a somewhat novice user I have run across a need and had to find most of this on my own. Thanks for such a great writeup and explanation.
First, it's not just just good regex support, it's easily accessible features from the command line so you can quickly iterate to a solution.
I'll often need to pull some very specific information out of a very large log file, and often Perl is the quickest way to achieve that. i.e.
# pseudo-code
head -n10000 LARGE_FILE | perl -ne 'next unless my ($foo,$bar) = /include/gsmi; ${foo}+=$foo, $h{$bar}.=$bar}; END { print %h }'
Once you're happy with results on smaller data sets with head, replace with cat. I used a similar technique to quickly identify, classify and determine the user account for a large set of hacked Wordpress accounts at an ISP I worked for.
Secondly, Perl is still the leader in regex development. They are still adding features that other languages are adopting (there have been a few good ides from outside they've taken as well, such as named captures, so credit where it's due).
In my production environment, it has the advantage of being installed as part of our default Unix build. Most of our devs use tools like Weblogic, webMethods, Informatica, etc., and a few of us old fogeys are still around supporting Korn shell and perl scripts we wrote a decade ago.
We don't have many bleeding-edge Linux hackers pushing Ruby, Python, Mongo, etc., which in my opinion is a shame.
LAMP originated with 'PHP' as the 'P'. It's also by far the most common, for better or worse; 1.4M hits for 'linux apache mysql php' versus 50k for 'linux apache mysql perl' on Google.
"Of course, there are plenty of excellent open source variants for any of the pieces of LAMP. Let the L stand for Linux, FreeBSD, NetBSD, OpenBSD, and Darwin/Mac OS X, all of which are open source operating systems and all but the latter have open source GUI layers. Let the M stand for MySQL and PostGreSQL. Let the P stand for PHP, Perl, Python, and Ruby."
I've never really had a problem with perl until I had to mange fairly large projects - including things like web frameworks or distributed modules.
Perl works best as CPAN glue. CPAN is wizards handbook, and you just have to write maybe 100 lines of code to glue everything together. However when it came time to write a large project on a team of even 2 or 3 people, managing a Perl project seems to turn into manager a C project. The "Theres more than one way to do it" mantra really sucks for people who learned Perl in differently. 00's university perl doesn't mix well with 90's hacker perl.
My huge problem with Perl is readability. Sometimes, across teams, there are just too many ways of doing some simple thing and one is plain perl code to one person, is a 5-minute and stare at this line hack to another.
Am I wrong? My experience is limited, but I would love to know why I haven't been able to get my Perl projects to "sync".
For me (in the data world) perl works really well within the unix philosophy. Basically my perl programs are small, simple, reusable, and can be piped together. My typical perl program is less than 200 lines and works on standard input/output (and perhaps a file or two provided as parameters). This simplicity and modularity means that I can pass my perl tools around to my team members and they don't need to read the code; instead they can read the documentation and unit tests and treat it as a tool. This takes advantage of perl's strengths, which are speed of development and built-in text processing.
Also, once you know perl you can easily write "one-liners", which have made me incredibly efficient in certain cases.
I'm wondering, did you utilize helpers such as Perl::Tidy and Perl::Critic? I imagine they may be able to help, possibly by standardizing the style enough (with Perl::Critic, which is configurable) that the problem is reduced to something you get with peer languages.
To be clear, I don't know whether this is true, but I'm extremely interested in people results.
The "There's more than one way to do it" sucks for trying to teach Perl too. You can't just teach one way; you need to teach every way, so that students can understand what they're seeing in the wild. This makes it take three times as long to explain the basics of Perl, simply because there are, essentially, three times as many basics.
My experience is different. I spent a lot of time in the beginning teaching the three or four important theoretical parts of Perl (lists, context, monomorphic operators, and coercion) and then explained how to use the documentation. That leaves only a couple of places where the difference between approaches is substantial enough that it needs explaining. Dereferencing syntax is one such wart. Choosing an object system used to be another place where opinions varied enough that it mattered, but now teaching Moose by default is obviously enough correct that it's a boring choice.
Yup. I've not taught perl for a while - but that pretty much matches my experiences. The N ways of doing "good" OO was the biggest problem I encountered and Moose solves that.
My huge problem with Perl is readability. Sometimes, across teams, there are just too many ways of doing some simple thing and one is plain perl code to one person, is a 5-minute and stare at this line hack to another.
I, personally, haven't noticed this happening any more in large Perl projects than with any other language. Yes they happen but, like with other languages, they're usually opportunities for team members to learn one thing or the other (either "this is what this does" or "please write comprehensible code to the rest of the team" depending ;-)
Perl still leads the pack on indeed.com. And I keep getting requests for Perl training. It is always interesting to see the disconnect between what is popular with programmers, and what is actually popular in the industry.
That's how it always was with Perl community, and I like that mature and calm attitude. "What's all that hype about? Ah, someone just reinvented yet another wheel [1]. Oh, kids these days, so loud, aren't they."
The Perl community is not so vocal, that's it and that's just pragmatic. Why yelling about nice tech you done? It works, it solves your problem, it's uploaded to CPAN, it's not a silver bullet, and that's OK.
Look at some Perl project like Cheater [2] - that's best tool for generation of test DB data available. Simple and extendable. And there's no hype about it. While I cannot even imagine an amount of hype if it were produced by Ruby guys (especially a couple of years ago) or NodeJS crowd.
[1] The bleeding edge in BigData'2013 - pipelening! So wonderful! Oh, wait a minute.. Is that Schwartzian transform we use from 1994?
Interesting. When I do some searches on the Dutch version of Indeed.com, I get very different results: Perl (421 hits), PHP (2397 hits), Python (493 hits), Java (3173 hits). The top of the Perl listings seem to be for system administrators, and are not a required skill. Contrasting that to PHP, where the top are all specifically asking for PHP.
I personally haven't spotted Perl in the wild as a serious programming language for a long time. Again, it seems Perl is mostly popular with system administrators without much programming experience. But that might very well be just my little corner of the world, which happens to be a hosting company.
Oh it's definitely still out there. Still used a lot in the finance sector in places. A bunch of companies have a stack of perl infrastructure that "just works" and want to keep it that way. Still folk starting new projects with it (Duck Duck Go, Bunchmail, etc.).
As many as PHP, Ruby, Python, etc. - maybe not. But new projects are still rolling out.
That's always the case outside of startup culture, which is why despite being a Unix/Linux guy, I end up in Visual C++ quite often and deal with all sorts of esoteric languages and tools. It's quite a bit more fun that sitting in front of say Python or Ruby only all day.
I've been trying to learn Perl 6 for a long time now. The PDF book is great but nothing beats a paperback style novel you can read anywhere. I got hooked onto Perl (long time back!) after reading the Programming Perl book (Camel book). IMO Perl 6 seriously needs a book release. No e-book, PDF, etc. just a old style paperback!
Anyone looking to work in perl (no need to be an expert, we'll teach you) and see why it is often the best tool for the job, and in a start-up environment in London, we're hiring: http://www.lokku.com/jobs/perl-developer-2013.html
My first language was C. The first language I loved was Perl.
Perl will always hold a special place in my heart and I will look back on it as the "good ole days", but I don't know if I'll ever program in it again.
For me, I don’t feel comfortable working without a static type system. I love Perl (and initially mistyped that as “live” Perl, which is nice), but nothing beats the feeling of the compiler going through the code for me. Granted, I still have the test suite, but that’s much more work than just getting the types right.
I'll agree with that. There's numerous times I've wanted to be able to assume (correctly) that a scalar holds a certain value type. At the same time, it sometimes feels constraining to design within that limitation. I think optional typing is the future here, and Perl 6 has it, as well as a few other modern languages.
That's a fair question. The title is "Why I (still) Love Perl", but the post doesn't really seem to get around to explaining that.
It's not really a "Why you should use Perl instead of X" either.
It seems more like, "Perl's Not Dead, It's Just Schizophrenic Now". It attacks the idea of "Perl is Dead" with a description of the rather confusing state of "modern Perl". It doesn't exactly make the ecosystem sound all that enticing, not here in 2013 when there are so many other viable options.
Well, in my opinion the article says Perl (5) isn't Rakudo (Perl 6) and therfor one should have a look at the thirteen years of Perl 6 development, but the Perl 5.x series, when wanting to learn about Perl?
I think the "Why I love Perl" part is pointed out by the community and that Perl 5 basically spawned Perl 6, which is a different programming language.
I pretty much agree that Perl 5's popularity is really low, despite lots of great minds and exciting approaches. I switched to Node.js, CoffeeScript, Go, etc., but it is like everything I do could have been better or equally done in Perl and the tools were more mature. It's the same with all the new concepts and always makes me think about the MVC hype, when the concept of MVC was first named in the 70ies. It's a bit like with Smalltalk. It took like 30 years until people ralizing how good it is and reinventing it.
Same with "Do things the Unix way", pipes, KISS, NoSQL, distributed systems, all the stuff that the EC2 made popular. In that sense Computer Science is a really slowly developing science. At least it appears like that, maybe others are similar. I don't know.
And what is happening right now for example is making Javascript C, while the developers of C are stepping towards dynamic languages (Go). Also functional progrogramming laguages reappear, first Haskell, now Clojure reapear, cause it is cool for async stuff. LISP has been around for ages and Scheme is really beautiful and neither of them was ever slow or anything. Just look at Racket. It's pretty powerful, amazing to learn, performs at least okay and its IDE is pretty nice and cross-platform. It's amazing for doing the same stuff as Node.js and Scheme is one of the easiest languages to implement.
But back to Perl. It has a lot of problems. Nobody ever talks about how awesome CPAN and CPAN-Testers is (you don't even need to set up Travis CI). Nobody ever talks about it as functional programming language, even though there is a great book about. Another problem is that it is way more optimized for getting actual problems done and doesn't really perform too well, when you show your average snippet that looks mostly the same in every programming language out there.
The last flaw is that Perl is probably the hardest programming language to learn, because there are so many bad books out there. There are books like Modern Perl, that even are free, but also many really bad ones.
And a lot don't tell you about use strict; use warnings; use diagnostics; right away, even when they are what every beginner wants.
That's why I find community initiatives like the Perl Tutorial Hub (http://perl-tutorial.org/) very valuable, especially for people just starting with the language.
They even have a page dedicated to sifting through tutorials and guides, and assessing their usefulness for learning Modern Perl - http://perl-tutorial.org/learn/
"the ecosystem". Somehow the article avoided mentioning the utter dominance of CPAN.
When CPAN dies, perl dies. Is CPAN still my best hope for "easy interface to something really weird but very important"? Oh it is? Well then Perl it will be.
I find it extremely hard to justify on the job writing and debugging something that "just works" off a 30 second install from CPAN.
Note this criteria doesn't matter much for boring CRUD webapp number 246264. There are somewhat more optimized solutions for that very small subset of problems.
I think most users probably don't particularly care about the hot air and ecosystem thing on the Internet - they're too busy using it to get stuff done.
These are the guys who if you Google their email address, it will show one or two posts to usenet between 1995 and 2013 and nothing else. No Twitter account, no Facebook profile, no prolific profile on Reddit or HN. Just silent work and go home.
Please don't take this the wrong way, but there's nothing wrong with being like that, right? It's not so much that there's nothing good to say - I just don't want to add to the clutter that already exists out in the web.
IIUC, the point is that Rakudo nee Perl 6 is a whole different community and language and all should move forward accordingly:
"I sincerely hope to see Perl 7 released quite soon. No fuss, no bother, no long list of “blocking features”. Just BAM! ship the next version of Perl (5) as Perl 7. And I sincerely hope the greatest success for Rakudo. I don’t even care if it takes another 13 years to release, it’ll be worth the wait."
That perl5 should just go to 7 instead of waiting for 6.
I remember a guy at a circa-2001 perlmongers meeting sullenly asking a visiting perl contributor "when is 6 coming".
The memory really influenced me. People really need a sense of momentum in order to feel confident in a community... same goes for a job and a lot of other things in life.
I learned Perl about 15 years ago and, while I love the language, am finding myself stuck in Perl from those days. Any resources I can go to to get myself up to speed with modern Perl practices?
I learned Perl about 15 years ago and, while I love the language, am finding myself stuck in Perl from those days. Any resources I can go to to get myself up to speed with modern Perl practices?
Perl is like records on vinyl. There are a small group of people who swear it sounds better, but as a commercial artist you definitely wouldn't release anything new on it.
I just spent a couple weekends putting that together. It's just a little toy, but it does exactly what I want, the way that I want it to.
I have to say I really enjoyed writing it. Specifically, writing it in Perl.
Writing Perl never feels like work to me. Can't say why, exactly. But I do know if I'd used PHP or Python instead, the pleasure of writing this app (as opposed to anticipating its completion) wouldn't have been there--I would have just persevered through it, in order to reach the final result. Totally different experience.
I 100% agree. It feels like having a fun conversation with an old friend. The kind of old friend you can not see for months, then pick up your last conversation again without any problem.
I think this really has to do with the language design being guided by linguistics principals than academic language design ideas.
With very little work, it's possible to write decently maintainable Perl as well.
Let's say I don't know any server side language. Why should I learn Perl when Php is ALWAYS loaded and configured on every single server, was literally built for MySQL, while Python and Ruby and hotter (and more intuitive) with better MVC frameworks and libraries behind them, why?
I'm not being facetious, I really want to know the reason I would do that. I buy the "Perl is better than C" argument 100%, but how is it better than Php, Ruby, or Python ESPECIALLY for someone picking their first server side language?
I'm not being facetious, I really want to know the reason I would do that. I buy the "Perl is better than C" argument 100%, but how is it better than Php, Ruby, or Python
Off the top of my head.
* I'd disagree that other languages have better libraries and frameworks than Perl. Perl has some pretty darn awesome libraries and frameworks.
* It has the best testing infrastructure in any language I have ever used. Period.
* The Moose OO layer has some really rather nice things for composing large OO projects
* Because something doesn't have to be better than another language to still be worth learning
* Because there's a shit load of perl out there - and knowing how to deal with it well will probably make your life easier.
* Because learning new languages always tweaks your perspective in useful ways in my experience
* Because the Perl "infrastructure" (CPAN, metacpan, CPANTESTERS, CPANTS, etc. etc.) is still best of class. I so wish I could have reports like http://static.cpantesters.org/distro/D/Dancer2.html in the Python, PHP, JavaScript or Ruby world.
* Because Perl takes backwards compatibility and keeping old code running very, very seriously. Shit just stays working.
Perl is also installed on virtually every server. Seems most people are using Ubuntu nowadays and it's definitely there by default (much of the Debian infrastructure is written in Perl). I believe the same goes for Red Hat.
As to your actual question, I'm not sure I'd say that Perl is better than Php/Ruby/Python. I really consider them all mostly the same. There are bits and pieces of each that is better than the others, but nothing overarching. If you know one of them really well, I don't see a huge reason to learn another one of them to the same level (unless some sort of outside influence compels you).
Perl's strength has traditionally been CPAN, but Ruby and Python both have their own copies and communities big enough that most of the stuff you look for is already there.
The Perl community's documentation is also superior to almost anything else out there. Once I've CPAN installed a package (say Template::Toolkit), I just "man Template::Toolkit" and there's a ton of documentation sitting there, including examples. The convention in the community is to put the example at the very beginning, which is heavenly, and cannot be appreciated enough.
In contrast, the Ruby community's documentation is largely a joke. It seems most of the time the documentation for a gem is in the README on github. And even then, to really learn it requires diving into the code. But then it isn't clear what is or isn't supposed to be a stable API. Perl seems to do that way better than Ruby.
Python always seems to have docs you can get to with pydoc but from what I've seen they tend to be auto-generated from the API with a lot of "FrotzBlubb() - This function Frotzes your Blubb" style non-documentation. So it has the sheen of documentation but it's not actually really helpful.
That being said, I learned Perl in 1994 or so and recently did a Ruby project. I quite enjoyed it and have been forcing myself to do new things in Ruby to keep up my language skills. I do miss the good documentation in Perl though (the Ruby community really needs to take note). Also Perl just seems faster than Ruby (I have no evidence, it just feels that way).
You might not be being facetious, but you have clearly already decided that python/ruby have better libraries for whatever definition of "better" you're using.
Personally, I'd avoid PHP as a first language because it's, well, kind of an abomination of a language even if the community have done some awesome things with it.
As for perl/python/ruby? I usually suggest to people that they should write at least some code in each of the three; you end up as a better programmer as a result and besides, it's fun :)
Then my suggestion to experiment with all three stands.
Things you might want to look at for Perl - Moose/Moo for OO, Mojolicious/Dancer/Catalyst for web frameworks, DBIx::Class/Rose::DB::Object for ORMs, App::cpanminus/App::perlbrew/local::lib for managing installations of Perl and modules, and http://metacpan.org/ for looking up libraries for everything else.
Also, the free book "Modern Perl" to get a feel for the language in 2013 as opposed to the hundreds of horribly outdated .com-bubble era tutorials you'll find on google.
You'd be best with somebody else's advice for python or ruby, most likely, so I shan't opine there.
Thank you all for your thoughtful responses! I really hope I did a good job conveying that I seriously did want feedback on this question, and my counter-arguments to Perl were simply to alert you to my biases going into the discussion.
Anyway, from these responses, I would say there is no compelling reason to learn Perl as a beginner or advanced-beginner, but perhaps for someone beyond that point there are some decent ones.
I did it the old-school way with no fancy framework, just CGI.pm. I made fun of myself to my collegues saying it was great to live in the 90s again. But actually, after a few hours coding it became clear that we haven't progressed very far.
It was a single script and it just worked. It was also much more fun than persuading a web framework to do what I wanted because I was actually programming and not configuring.