Half My Life with Perl
perladvent.org
perladvent.org
Perhaps at the core of this just how many what we called regular programming tasks are just knowing how to work with text and unixy operating system. Perl is just unbelievably awesome at this. Another big edge of Perl is commitment to backwards compatibility, most people who learned Perl early in their careers decades back can use it on-demand basis. Its universally installed, fast and scripts written from the earliest days continue to run with 0 changes, despite endless OS upgrades.
Early enough in the timeline Perl was full unix hackers, and you learned a lot from them, this culture further bolsters Perl's productivity credentials. Not a week passes, that I have to whip up a Perl script to do something for someone has a 2 people and a month budget to do. And they are often amazed it can be done this quickly.
CPAN is another big edge Perl has. No other language apart from JS/npm ecosystem has anything close, and these are basically competing in very different domains so to that end CPAN really doesn't have a competition till date.
If you are looking to build using Perl do checkout the Camel book and HOP by mjd.
I'm not aware of anything that can be as effective at text processing as perl. While I don't do much perl anymore, if I have to wrangle text files in all kinds of ways, there is no comparison, perl rules.
Ruby really is competing with Python in problem domain space not Perl.
I cut my teeth on Perl and I still remember it fondly. But there is no reason to learn Perl (5) over Ruby. Maybe Perl 6 is a different story though.
Perl (talking about Perl 5, don't know anything about Raku, don't want to know anything about Raku) simply treats strings as sequences of numbers without requiring numbers to be in the 8-bit range. This makes it easy to say that those numbers could in principle be Unicode codepoints. The problem is that the actual assumptions about what those numbers represent are implicit in programmers' minds, and not explicit in the language, much less enforced in any way. The assumptions shift as strings are passed between different libraries, and sometimes different programmers working on the same codebases have different ideas. Perl will happily do things like encode an already-encoded string, or decode an already-decoded string, or concatenate an encoded string with an unencoded string, or reverse a utf-8 string by reversing the encoded byte sequence, etc. etc. So it's easier in Perl than in any other language I've ever used to end up with byte salad.
It'll take you, let's say, the first few years of your Perl career, involving painstaking testing of everything you do with nontrivial characters, to truly grok all of that. But the problem is: You're not alone in the world. If you work on a nontrivially-sized project in the real world that heavily utilizes Perl, then byte-salad will be what you will get as input. And byte-salad will be what you will produce as output. It is frustrating as hell.
Unicode was a pretty painful matter in the transition from Python 2 to Python 3, but Python's approach means that the Python ecosystem is now pretty usable with Unicode. This is not the case with Perl at all.
foo.sort { |a,b| a.expensive <=> b.expensive } # basic
foo.sort_by { |a,b| a.expensive <=> b.expensive } # Schwartz-enabledText processing though? Nope. perl is immensely better at that. And of course in unix text processing is life.
But apart from that, I was nodding through your whole comment… Perl really is a super power. POSIX at your fingertips!
The real deal with Perl is you not only get bleeding stuff, you get all kind of obscure and rare libraries. Its not that you can't do that in Python. Its just that the culture in Python world isn't made up of people who think about those problems or even in that dimension. Its a great language for writing all variety of apps.
Perl is the og hacker's language. Python is awesome too, but its not really what Perl is.
Most of the bad rep Perl gets is because programmers who only interact with http endpoints and databases tend to not understand where else it could be useful.
Like even the regexes. They sound like a pain, until you have to do non trivial string manipulation tasks. Then you discover, regexes do it a lot better than cutting and slicing strings some 100s of times.
In the real world, the ability of a lone genius to cobble together a script in an hour is actually not that much of an edge -- it is more important for people to write something that others can understand and maintain. If you can do that in Perl, great, and if writing Perl makes you happy: also great. But beware that smug elitism turns people off, it kills communities and also tends to signal a pathological inversion of priorities. All this should be in service to people, after all
As a solo dev it is a massive advantage to use sophisticated languages and tools without worrying if the dumbest person on my team can use them. It’s a strategic advantage and I run rings around far larger companies.
You lose me with the smugness. Make no mistake, you aren't smarter or better than someone else purely by virtue of your willingness to hack on BEAM languages or smlnj or Racket or whatever languages you like. There are probably people smarter than you working in sales at $bigcorp or writing C# on Windows Server 2008 at your local utility. Novice programmers often have an instinct to rewrite systems from scratch when they should be learning how to read and understand code others have written. Similarly, I associate smugness of this form with low capacity for navigating constraints that tend to arise when solving difficult problems in the real world. The real world isn't ideal, sorry to say
I could readily believe that your stated reality is true of the majority of solo devs, but it’s not true for me or those that I know. I understand that my sampling is biased and probably not the normal experience. I don’t seek to show off for my anonymous HN account and instead wanted to say that sometimes we can have nice things and it can work out successfully.
Any success I have had in getting very boring companies to adopt nice things at all has not come from insulting people's intelligence and acting like I'm the smartest person in the room. I despise this kind of elitism that is rampant in certain technical communities. It turns people off like nothing else and serves no purpose other than to stroke your own ego -- it's pointless meanness.
My goal has not been to fix big companies for a long time, I was just musing on the rational and commented to see what other people think on the topic.
> reduction of the worker to a fungible interchangeable cog
And every solo dev that I ever met thinks they are God's gift to the world -- "tech geniuses". Most of them are just working on their own Big Ball o' Mud, just like the rest of us working on a team.
Your sampling of solo devs could very well be biased, similarly so could my sampling. Not working on a big ball of mud is a massive perk of being solo dev. It’s my company and I’ll refactor if I want to.
Any macro/multiplier is that way. You don't miss it, until some one shows you how to do it.
In the last six months alone the scenarios where I had to call upon Perl to help slam dunk a thing insanely laborious are dozens in number.
Its just that if you don't know this, or don't know it exists, you grow up being comfortable doing manual work with comfort.
Sheer amount of times, I have seen some one spend like half a day doing things which can be done using a vim macro in like seconds is beyond counting at this point.
This is a unique combination, which I don't think will ever change. Unless of course we move away from Unixy operating systems to something entire new.
It matters little that you can generate code in an hour that would take your colleague days. It is nice for you and it provides a short lift for your team, but in the limit what matters is maintainability. Peter Hintjens writes fondly of metaprogramming and code generation, but also warns that it makes it difficult for others to work with you, and it's easy to fall into the trap of building abstractions for their own sake. The "edge" in technical work comes from seeing both the forest and the trees, and missing that technical work is in service of humans, first and foremost.
I am glad you enjoy writing Perl, and I like encountering people passionate about it in my work. But I still think there are good reasons why it's in decline, and Perl users should reflect more on that rather than assuming people aren't using it because they are dumb / not technical enough / don't think about problems as creatively or deeply.
For the first category you’re right - these days there’s not much difference between Perl vs Java vs Rust because abstractions are the same.
But where OP’s smugness comes from I totally agree when applied to the second category - there’s an ocean of a difference between using tools like Perl, awk, sed, jq, and bash to transform Unix command inputs and outputs that it really is a massive superpower. Try doing a day’s work of a Unix admin using these tips compared to writing Java to do it. Oceans I say!
But I don’t think their being a basement dweller genius as you put it is because of Perl - it’s the smugness for the same reason why BOFH Unix sysadmin got their reputation - their tools are literal superpowers compared to GUI tools etc and they can’t believe everyone doesn’t use them!
Here's the reason: these languages/tools are tactically very powerful. Tactics are immediate and decisive. Tactics are effectively tricks in the sense that if you can "spot the trick", you can -- with a tiny amount of work -- reduce a formidable problem to virtually nothing. Having a vast toolkit that facilitates such tricks is incredibly powerful and makes you appear to have superpowers to colleagues who aren't familiar with them.
But tactics are definitionally short-term. You deploy them in the weeds, or at least from the forest, (hopefully) never from the skies. Tactics aren't concerned with the long term, nor how things fit together structurally. They are not concerned with maintainability or architecture.
This is why it isn't actually that important that you can cobble together a 15 line Perl script in an hour to do something that would take any of your colleagues a week. Years from now, when you are gone and someone runs into a similar but slightly different problem, someone will find your Perl script, not understand it, and rewrite it all in Java anyway. Or assume it's too hard and give up. Maybe they will adapt your Perl script, but more likely it'll be seen as a curiosity
It sucks, because there is beauty in that approach of solving problems. As I said in another comment, I wish there were more diversity in tooling and languages. But at the same time, it's important to consider that people are fundamental. All of this is in service to that. And I personally would rather build software that people use over the long term.
I think there's a deeper truth here. Perl was notoriously difficult to make C language extensions for. Languages like Ruby and Python really took off because they had a much more approachable and useful C interpreter API which; honestly, made gluing various library APIs into the language far easier. This being the key to taking a very slow and memory hungry scripting language covering a fraction of POSIX into a useful domain extension and embedded language.
Ruby did better at the domain extension part and Python was better at the embedded language part. Perl 6 went entirely the other way. I think this was the real driver of popularity at the time. This also explains why gem and pip are so different and why pip never matured into the type of product that npm is.
XS wasn't _that_ bad once you got the hang of it; anyways, but I do remember ruby 1.6 coming out and being blown away by how improved the experience of creating distributable C modules was. The class system was flat and easy to access, you could map ruby language concepts into C almost directly, and the garbage collection system was fully accessible.
perl 6 started being discussed right around this time and I think it was clear in the early years that it wasn't going to try to compete on these grounds at all instead focusing on more abstract and complex language features.
Anyways.. even seeing your name just brings me back to that wonderful time in my life, so don't get me wrong, I loved perl, but that was my memory of the time and why I think I finally just walked away from perl entirely.
Also, same as you though - happy to see Randal’s name pop up here :)
> beware that smug elitism turns people off
In my experience, the biggest problem with Perl is readability. Python crushes it. Without list comprehension, it is also very slow during for loops. But, no worries: Most people writing Python don't care too much about speed, or they are using C libraries, like NumPy or Pandas or SciPy. I write this as someone who wrote Perl for years, personally and professionally. Later in my career, I came into Python, and realised it was so much easier to read and maintain large code bases, compared to Perl. To be fair, much like C, it is possible to write very clear Perl, but people quickly get carried away, using insane syntax. With Python, the whole culture, from the bottom up, is about readability, simplicity, and accessibility. I think my only "gripe" about Python is there are no references like Perl, but you can fake it with single-item-lists.
Probably the lines "Its just that the culture in Python world isn't made up of people who think about those problems or even in that dimension."
and "Most of the bad rep Perl gets is because programmers who only interact with http endpoints and databases tend to not understand where else it could be useful."
I'll say this as someone who still does more than 80% of his backend work in Perl: This is not true. I wish it was.
CPAN was awesome once. Now it's mainly old. Yes, you will find obscure things which you won't find for Python. At same time, anything interfacing with modern stuff is often only 40% done in CPAN or not at all compared to the Python, PHP or JavaScript eco system. Not talking about data science stuff here, where Python gained a huge lead - simply have a look at how much support you get nowadays in CPAN for interfacing with, for example, current web api versions or interfacing with third party files like docx, pdf, excel, odt. If there's support for things at all, it is so far far far behind to what libs in other ecosystems have to offer, most of the time.
It simply shows that the crowd implementing business applications went elsewhere, so anything in that area seems stuck in the 2000 to 2010s in CPAN.
> Node/NPM definitely is on-par with CPAN. But pip isn't even close.
I did one small project with Perl but wasn’t excited. I was hoping for bash 2.0 but the shell integration wasn’t great. Seems like python is a similar feature set, less exotic, and has great libraries.
Anyway? What did I miss? anything I should take a second look at?
Never really did much with it, but it was enjoyable to learn.
LLM do Perl well enough, and since 90% of productivity with Perl is earned through small snippets or one-liners (anything bigger is better served with uv init --script), you can just ask the bit you want when you need it. You can even ask the AI to explain the hieroglyphs.
Same with bash, awk or powershell.
To my horror/surprise, not necessarily so any more. A whole lot of the OS parts that used perl have been ported away, or no longer part of the OS. It's entirely possible to run production workloads on RHEL without perl installed, for example.
I had a nice perl script I'd written ages ago that I sort of trundled around with me for a while, that could extract multi-line stack traces from plain text logs if any of the lines matched a certain string, and couldn't because no perl. I had to quickly rewrite it in python (wasn't hard to do, admittedly)
Not a strong opinion though, i haven’t been writing perl in a while.
Python was always the "rotting batteries" for me.... write something, some migration script, run it, works, forget. A few years later, new servers, hey, guess what, python 2.6 script has problems running on python 2.7... luckily a small fix. A fw years go by... new servers,.. hey, python 2.7 is not installed by default anymore, and pip has issues with dual versions... fix that. Few years... python 2.7 not even in repos anymore...
It's like that battery powered gadget, you use once every few years, and leave the battery inside, only to find out they leaked by them time you need to use the device again (duracell, i'm looking at you).
With perl it's more like a solar calculator... turn it on, it works, do whatever, put it in a drawer and forget about it for the next few years.
I think the batteries metaphor was meant to refer to the std lib, or (for Perl) the "CPAN" modules that are part of the core. The Perl core always keeps those batteries charged because they can't do a release if any of those are dead. They even ejected problematic modules, or those that were long since defunct, from the core so they don't have to deal with them. Python went through this exercise as well: https://peps.python.org/pep-0594/
The core Perl devs will also go to great effort to test against the entirety of CPAN ("blead breaks CPAN" testing), but some of those distributions haven't been maintained in decades so they have to draw the line somewhere. Fortunately if it's on CPAN then it's forkable (for the most part) so someone can take up maintenance.
Fortunately, new version realises of perl don't break CPAN modules that much. But there have been a decrease and of programmers that have either moved on or are passing away.
Without a younger audience not to maintain they're left to rot. Python will encounter the same when a new language hits the block in years to come.
I could always go with the MySQL interface, but I'd prefer to stay native if possible.
But then I had to change the code behind a different database table and the function that backed it did not exist in the codebase. I found the code that called the function, but the function definition itself was nowhere. I was literally stumped and spent hours thinking our versioning system (Source Safe) had failed, or that I had been given the wrong codebase or that there was some library being called into, to no avail. (We were using TextPad back then, no IDE.)
And then I found it: AUTOLOAD. If you're not familiar, if you call a function that does not exist in Perl, then Perl will call a sub-routine called AUTOLOAD if you define one. In there you can do whatever you want and the developer who had written this particular system was parsing the function name to identify the database table and fields. So something like `set_customer_name` would set the `name` column of the `customer` table. It was both genius and horrifying.
No, it was just stupid and horrifying. Something like `set_db("customer", "name")` would have yielded the same functionality with no obfuscation.
This was more approachable in Perl, than Tcl or later Python, as Perl does expose most of UNIX API on its standard library in a more C like fashion.
My Perl 5 camel book got a fair use back in the day.
These days I write TypeScript full-time, which I like, and there’s a lot I miss about Perl, while absolutely loving the types in TS. The few months I spent writing Python professionally didn’t convince me it was any simpler or better than Perl, and I quit that job to go back to writing in TS.
With the addition of 'let' - which to my brain is just "how javascript decided to spell 'my'" - I'm actually really quite enjoying it.
(and the javascript proposal for 'match' is written expecting the proposal for 'do BLOCK' to happen, and 'do BLOCK' is going to make me a _very_ happy mst)
I do not write it to win an obfuscation contest. I like it to be read as easily as possible. It is a joy to watch the core objects of the system work together so cleanly.
The general advice here seems to be “learn Perl while young”
I don't think anyone tried seriously addressing that use case after Perl. Like, obviously you can do text processing in any language, but you're not going to be doing it in the context of shell pipelines and one-liners. The preferred interaction modes are totally different.
It seems like fewer even want to learn a shell pipeline.
But I would love to know if there is a non-regular expression language with native support for csv, json and yaml that one can pipe files in and out of.
I generalised your statement for you. When people learn anything in their youth, they tend to think of it as "better | easier | True".
It's true for the things we call culture, language, religion, and relatively simple phenomena such as cuisine and programming languages.
We form a personal canon from the first cognitive imprint. It is hard for people to change even when confronted with bias. The programming community is no exception.*
* pun intended
>>The general advice here seems to be “learn Perl while young”
Best time to a plant a tree was 20 years back, Next best time is now.
- A Chinese Saying.
https://english.stackexchange.com/questions/603690/origins-o...
Seems like it _may_ not be Chinese. I've often seen it attributed as Chinese. Funny how that sticks.
This works because perl is layered. To do even fairly elaborate awk-like text processing you only need to learn a little perl. Nothing like all of perl. To do the rest (of elaborate text processing), you learn a little more. In the end, most likely you never need to learn all of perl. But it's there to add to your toolbox as needed as you go.
I find piping into python to be a lot more than 2-3 lines before I'm even ready to do any manipulation of input, which again can get quite verbose. So I'm guessing it is not python.
echo -e "foo 1\nbar 2\nbaz 3" | ruby -n -e 'BEGIN { puts "===" }; $_ =~ /^b\S+ (.*)/ and puts "#{$_.chomp.upcase} => #{$1}"; END { puts "===" }'
Perl had three huge advantages (at least for me) when I first used it in 1992: 1: familiar syntax which paralleled well-loved tools (sed, troff, grep) 2: associative arrays as a built-in 3: regular expressions as a top-level language feature (not buried in some library with clunky syntax). A few years later, CPAN was another huge advantage.
Nowadays, syntax compatibility with sed is a disadvantage not advantage, associative arrays/dictionaries exist or are easily available for basically every language, and CPAN was the model that everybody else copied or did better. So really the "regexp syntax is immediately available" is the only remaining advantage, and it's rare that it would be worth it.
I think what people are actually saying is: "Perl was great in certain regards, back when I could expect my colleagues to understand Perl, which incidentally was when I was young"
It may take many more likes to apply a regex in any other language - but if my colleagues know Python but not Perl, saving 10 minutes of coding will cost me 5 hours of training/coaching/debugging after the code has been 'maintained' by someone who doesn't know their $_ from their ->@*
I personally find python most useful to learn, especially in combination with invoking a real editor to edit multi-line commands:
bash has C-x C-e and the `fc` buildin, other shells have equivalents.
https://www.gnu.org/software/bash/manual/bash.html#index-edi...
I have extensively used awk and it's lacking when mid size problems become larger projects.
I also have used perl quite a bit, and if you love the "sigil" you can become very, very happy with perl. I personally never go warm with sigil, I have developed sigil-itis, so to speak.
The Camel book was so well-written. It was my introduction to Perl, which became my "superpower" in the 90's and far longer into the 2000's than I tend to admit. I eventually switched to Python because it's the closest thing that is considered an acceptable "modern" choice. I really enjoy Python too, but the obligatory XKCD about Python[1] rang true for me about Perl first.
For me the #1 superpower strength of both languages is the first-class treatment and syntactic sugar for associative arrays (a.k.a. hashes, dictionaries).
Perl did the same for regexes and file I/O; Python did not.
I have come to appreciate Perl's backwards compatibility -- that old scripts still run unchanged -- though maybe that's largely because Perl 5 has been in maintenance mode for so long.
Perl 5 has been adding features consistently over the years, not just fixing bugs. Many people just ignore the new features, but you don't have to.
I can name: dynamic scoping, implicit filehandles, implicit $_, strange contexts, keyword-like list functions. That’s basically it, and while it sounds fun, it doesn’t do much in a sense of code reduction.
$. $? $$ etc, well you can split lines with .split('\n'), get status as a part of result, call os.getpid().
<>, you can open() or createReadStream().
$_ is just a kids toy. “print if /…/“. Cool.
Lots of global modes under dynamic scoping is questionable. Value semantics and corresponding sigils are horrible, really. Bless is ugh. Subs are meh.
It’s all just regex. Add regex as a language construct and you get the power of perl in it. /…/.test(s), s.match(/…/), s.replace(/…/, '$&') that’s 90% of Perl. Regex saves most lines of code, everything else is just esoteric extra that doesn’t do much. Also no GC.
Let's say I'm talking to a human programmer. I say, "Read in a line of text. If it ends in a newline, remove the newline." Cool.
But when I talk to a computer, I can't talk that way. It says, "If what ends in a newline?" It doesn't understand "it".
Except in Perl. In Perl, $_ is "it". It's what we're talking about if I don't specify something specific. It's where the line of text gets read into if I don't specify a destination. It's where the newline gets removed from if I don't specify a variable. It lets me ignore specifics when I don't care about those specifics. It makes Perl much closer to how we talk to each other instead of how we talk to computers.
if (line ~= /\n$/) {
line = chop(line)
}
You may argue that other languages don’t have it either, well that’s true. Standard libraries usually suck compared to what perl does out of box.
But when the task at hand grows just slightly bigger, to the point where I know I'll need to pass filehandles to/from my own functions, my skin starts to literally itch because of how bad the filehandle situation is.
It's not plain "open F, ..." any more... Is it "*F"? Is it "\*F"? Are those the same thing? (What the hell is a "typeglob"?) Wait, can't I just use "open my $f" and everything works the way it obviously should? Well, kinda, unless you want to be able to store an existing filehandle like STDIN in there, then you have to do something different again... Do I need IO::Handle instead? (Why does that need to exist...?)
open my $fh, '<', $filename or die "Couldn't open ${filename}: $!";
use File::Open qw(fopen);
...
my $fh = fopen $filename;
sub foo {
if (whatever) {
open my $fh, ...;
return $fh;
} else {
return \*STDOUT;
}
}
demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;'
HELLO
Line: HELLO
demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;' -
HELLO
Line: HELLO
demeisen=; echo 'HI' >tmp/hi
demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;' tmp/hi
Line: HI
demeisen=;qw, qr, references, multiline regexes, a far advanced OO ecosystem, Data::Dumper, map, grep, pack/unpack, DBM, ``, top class unicode handling, given/when, functional programming etc etc.
In fact I've barely scratched the surface.
You must grok Perl more.
top class unicode handling
This one I remember struggling with, afair due to io vs perlio layers impedance mismatch and use utf8. Not sure about now, but perl was anything but unicode for the clueless.
Moose is definitely what I go for when I have to use OO with Perl, this more than a decade old and stable for production use cases.
Its based on Class::MOP, which is in turn based on Meta Object Protocol, the same concepts on which CLOS(Common Lisp Object System) is based on. Its always nice to have CLOS goodness in Perl. For eg- https://metacpan.org/dist/Moose/view/lib/Moose/Manual/Method... these methods like before, after, around do fix need for design patterns to a large extent.
But of course the more you explore, the more you discover the possibilities with this.
To a large extent I think Perl brings OO and functional paradigm in a far better package than Python does.
Perhaps HOP needs a new chapter for OO given how few people are aware of this.
Moose out of the box has its own set of problems, leading to other workarounds, e.g.
Moo (a similar but much less bloated solution)
MooseX::Extended - Moose with more sensible/correct defaults
https://metacpan.org/dist/MooseX-Extended/view/lib/MooseX/Ex...
In practice, this has turned out to be a mixed blessing because of how tedious it is to do this repeatedly. So over the years there have been many libraries created to make this easier, each with different features.
There's currently work underway to modernise Perl's built in OO to address these problems.
On the other hand, this makes some things easier, e.g. Design by Contract can be added to Perl just by writing a library.
Another example, adding traits to PHP required updating PHP itself, whereas in Perl there are libraries to do that.
References are a PITA - cumbersome to use, and they make code less readable.
Perl doesn't have first class functions (you can pass or return functions via references, but that's cumbersome and less readable compared to languages with better FP support).
given/when won't be removed, too much back wards compatibility issues.
>>References are a PITA - cumbersome to use, and they make code less readable.
Depends what you mean readable though. In python you can't tell whats a variable and whats a list, and whats a dictionary by looking. One can claim whole language is unreadable since variables are needed at every step.
>>but that's cumbersome and less readable compared to languages with better FP support
Sure let them add all the other practical goodness of Perl, then we can use them.
% perl -v | head -2
This is perl 5, version 40, subversion 0 (v5.40.0) built for x86_64-linux
%
% perl -E 'use feature "switch"; my ($x, $y); given ($x) { $y = 1 when /^abc/ }'
given is deprecated at -e line 1.
when is deprecated at -e line 1.
Smartmatch is now seen as a failed experiment and was marked as deprecated in Perl 5.37.10.
This includes the when and given keywords, as well as the smartmatch operator ~~.
The feature will be removed entirely in the Perl 5.42.0 production release.
>> In python you can't tell whats a variable and whats a list, and whats a dictionary by looking.
In Perl, sigils are used to distinguish between scalars/lists/hashes. Sigils and references are not the same thing.
yes, enables brevity.
yes, probably comprehensive offline std docs.
,...
https://perldoc.perl.org/perldiag should set off some alarms.
In fact, even modern JS frameworks with features that have no equivalent in Laravel/RoR/Django see their appeal diminished because those old school frameworks do the basic so well they are productivity cheat code for essentials.
It's so easy to find people delighting in beautiful hot reload yet struggling for days making Oauth work or having to pay a saas for image resizing while 20 years old tech have that part nailed down.
Django's admin alone is richer in feature than this whole framework.
Web frameworks:
https://metacpan.org/pod/Net::API::REST
Middleware:
https://github.com/miyagawa/Starman
Some other useful stuff...
OO Frameworks:
https://metacpan.org/pod/Moose
Type system:
https://metacpan.org/pod/Function::Parameters
https://metacpan.org/pod/Function::Return
Coroutines/multithreading:
https://metacpan.org/dist/Coro/view/Coro/Intro.pod
Async:
https://metacpan.org/pod/Future
https://metacpan.org/pod/Promises
https://metacpan.org/pod/IO::Async