Half My Life with Perl(perladvent.org)
perladvent.org
Half My Life with Perl
https://perladvent.org/2024/2024-12-19.html
138 comments
> You really have a mad productivity work horse.
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.
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.
Keep Higher Order Perl for later. It's great but far too much for a 2nd book when getting started. The camel book Programming Perl is still a great start which adheres to the layered aspect. Don't read all of it, just a few parts as needed. I recommend to add Perl Cookbook early, to look things up as you go - it gives idiomatic-ish ideas of how you might do X in Perl. Perl comes with a mountain of very complete and useful man pages: you start with looking things up in the camel book, then transition to looking them up in the man pages.
Just curious, what does Perl give you over Ruby if anything? I learned Ruby first, always heard it was strongly inspired by Perl (as well as Smalltalk), and it provides all the benefits you mentioned, I think.
Mostly because Ruby isn't as ubiquitous and its not closer to C, the way Perl is.
Ruby really is competing with Python in problem domain space not Perl.
Ruby really is competing with Python in problem domain space not Perl.
One liners. I dropped ruby when it could not express various one liners as well as perl can.
Frankly nothing. Ruby is a strict improvement over Perl in almost every way.
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.
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.
I believe Perl got Unicode to a usable state long before Ruby. Ironic, given Ruby's origins.
It's not a race. Perl got there fast by basically not giving a damn about anything.
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.
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.
I've had the complete opposite experience. If I need to do more with non-ascii text then treat it as an opaque blob, I still haven't found anything better or easier than perl to do it in.
On the other hand Ruby has the Schwartzian transform baked in :)
foo.sort { |a,b| a.expensive <=> b.expensive } # basic
foo.sort_by { |a,b| a.expensive <=> b.expensive } # Schwartz-enabled[deleted]
[deleted]
I looove ruby. It is my favorite scripting language for nearly everything.
Text processing though? Nope. perl is immensely better at that. And of course in unix text processing is life.
Text processing though? Nope. perl is immensely better at that. And of course in unix text processing is life.
Sadly I think Node and Python have long taken over CPAN.
But apart from that, I was nodding through your whole comment… Perl really is a super power. POSIX at your fingertips!
But apart from that, I was nodding through your whole comment… Perl really is a super power. POSIX at your fingertips!
Node/NPM definitely is on-par with CPAN. But pip isn't even close.
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.
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.
I'll be frank: I think this idea that ${faveLang} is for misunderstood geniuses who truly understand computers where mainstream languages like Python are for dunces who only know how to glue together APIs is a large part of why such languages as Perl are nearing extinction. It turns out that there are people working on challenging problems in domains you've never heard of in Python -- and pretty much every other language. Give it a rest
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
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
I wonder how much of catering to the lowest common denominator / being a team player is an internalizing of corporatisms reduction of the worker to a fungible interchangeable cog.
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.
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.
I agree with you that it is sad there isn't more diversity in languages and tools, and that generally organizations are using the same terrible slop. We could have such nice things
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
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
That sounds like post facto rationalization, sour grapes, and perhaps a bit of learned helplessness. To paraphrase you ‘We can’t have nice things because nice things are in reality bad and unrealistic. People who do have nice things are not special.’
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.
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.
It's not learned helplessness et al, just a plea to drop the smug elitism if you want people to take you seriously. I actually want nice things, I hate writing brittle systems in languages that offer no meaningful guardrails, and setting up Rube Goldberg contraptions to get a poor approximation of e.g. basic BEAM runtime functionality.
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.
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.
I worked applied research at a few very big companies and did have a measured amount of success getting some advanced tech adopted so I know what it takes to move the needle. My lesson, and one I wish I learned sooner, was that the effort was not worth it. I had assumed that the lack of adoption was due to lack of exposure to ideas but having exposed these ideas to a large number of people I reluctantly came to the conclusion that it more of a lack of innate intelligence. I honestly wish it wasn’t so.
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.
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.
[deleted]
> 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.
If only the highest skill devs could quickly learn new projects then they are no longer interchangeable.
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.
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.
[deleted]
>>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
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.
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.
The superpower here is a scripting language, not Perl specifically.
Sometimes a language/tool gets to evolve with the operating system right at their birth. The relationship with between Unix, vim, and Perl is that way.
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.
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.
You are missing my point. For transparency, you are talking to someone who writes Racket in emacs on my Linux desktop, has used Rust macros to clean up awful code in widely used open source packages, and regularly generates code for all manner of purposes in lots of different languages. I know the slam dunk feeling of generating exactly the code that will topple a problem -- and I also know it's not actually that big an edge!
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.
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.
I personally believe there are 2 types of Perl - development which you’re talking about here, and sysadmin/devops.
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!
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!
I use nearly of these tools with the exception of Perl. I go to great lengths to make sure I have access to them because it's so critical for quality of life. I love them and I understand why people love 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.
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.
> who only know how to glue together APIs
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.
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.
Inline::C did a good job of reducing the barrier to entry for C code.
True but I don't remember it being nearly as convenient to distribute those modules as it still required the whole build environment on the target and you still had to deal with perls exceptionally efficient but ancient and cumbersome object and type system.
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.
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.
Inline:: was a world of a difference! I was so intimidated at the time with XS but Inline:: was almost magical.
Also, same as you though - happy to see Randal’s name pop up here :)
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.
> I don't know what caused this reaction.
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."
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."
> Node/NPM definitely is on-par with CPAN. But pip isn't even close.
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.
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.
Regex and slicing are not the only options. I find that people tend to over estimate how hard it is to write a basic parser.
I’m into lisp and vim.
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?
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?
Raku is basically perl 6 and has some features that blew my mind when I tried it a few years back.
Never really did much with it, but it was enjoyable to learn.
Never really did much with it, but it was enjoyable to learn.
This encapsulates every conversation I have ever had with someone who tried Perl 6: Tried it, was blown away with [some aspect of it], never found anything practical to do with it, never used it again.
I think I even reference that in the talk... Dart is everything I wanted from Perl 6, which is why I'm happy to be coding in Dart now.
If you're into Lisp you're probably not missing that much. The main reason I use Perl over Lisp is that Perl is preinstalled nearly everywhere, whereas Lisp is not.
You should really look at Tcl if coming from Lisp and wanting a bash successor. Tcl (8.5) is also preinstalled on MacOS.
You don't need to learn it now anymore.
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.
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.
Perl is my first love, and I still whip it out from time to time to do system tasks (anything in the linux world). It is literally installed on any *nix OS, macOS included. Python is fine, but it’s not as universal as Perl. I also feel like Perl is more “batteries included” as many times I can be productive without “use”ing any libraries. It’s has been my secret weapon over the years. I’ve also noticed that most younger engineers don’t know it, and if they know any scripting language at all, it’s of course python.
Indeed. As a younger engineer I learned Perl during a brief stint as manager (because I didn't have time to do real programming, but I still needed to automate things). I have no regrets. It is one of the most useful languages I know, transcending what I do for a living.
> It is literally installed on any *nix OS, macOS included.
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)
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)
MSN Messenger contact bots got me in to perl back at 15, 35 now and still coding it for work as a legacy maintainer. Pays well.
Nice similar age, I got into it as my first job after university and every job since
My experience with Perl is that often the batteries are rotting.
Not a strong opinion though, i haven’t been writing perl in a while.
Not a strong opinion though, i haven’t been writing perl in a while.
The analogy is quite the opposite here.
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.
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 never mentioned python in my comment, though
> My experience with Perl is that often the batteries are rotting.
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.
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.
Can you give a specific example?
I can't recall what modules my boss created but he had heart attack and passed away. So his modules are now left unmaintained.
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.
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.
This is terribly sad to hear. Perl used to be so ubiquitous and it is sad to see that it is rapidly fading away. I know of no one in my friend circle who has EVER used Perl.
Perl has been my go-to language for years now. Just yesterday I needed to write a little tool to stream some scraped metrics into a ClickHouse database. I was shocked to see that there aren't first-class Perl libraries for ClickHouse, and those on CPAN are seemingly fairly old/unmaintained. That's a real bummer.
I could always go with the MySQL interface, but I'd prefer to stay native if possible.
I could always go with the MySQL interface, but I'd prefer to stay native if possible.
My first experience with Perl was back in 1999. I was fresh out of university working at a dot-com start-up web agency and was asked to take ownership of a project after the developer had left the company. It was pretty straightforward CGI project, with some functions that aligned one-to-one with the database tables. Quite clean code. I made the changes I needed to make easily enough for the first couple of bug fixes or features.
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.
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.
Python has import hooks, which you can use to do the same madness. I imagine many languages have some form of lazy loading to do roughly the same thing. I suppose it's more the culture of the language than the capabilities driving whether someone actually uses something weird like that.
A procedural/imperative ORM, quite neat actually
> 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.
No, it was just stupid and horrifying. Something like `set_db("customer", "name")` would have yielded the same functionality with no obfuscation.
My then-girlfriend and I, kicking it O'Reilly style, 1996: https://i.imgur.com/PPmZs9P.jpeg
I had quite a few of those animal shirts, along with many Stonehenge party shirts. Gave most of them away since I wear collared shirts now that I'm a grown-up.
Nerdy, and sweet. I needed something positive this morning.
Despite being famous for being a cryptic language, in most cases in UNIX world, the safest way to code was to do userspace stuff in Perl, and only if it really mattered, rewrite in C.
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.
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.
[deleted]
I’m 42, and learned Perl at 14. I’ve worked with some very large Perl systems, and love it. Yes, there’s bad Perl, but I’ve never really understood the hate for it. The testing ecosystem and culture and documentation culture are first rate. The tooling like Mojolicious, DBIx::Class, etc are super well done.
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.
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.
I can't cope with python because of the lack of 'use strict' - I continue to be sad that 'explicit is better than implicit' is supposed to be a rule of python except apparently not for variable declarations (also I want block based lexical scoping damnit).
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)
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 love perl. I work with it every day still, 25 years later. I recently rewrote a cellular provisioning API in it to be fully object oriented.
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.
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.
I’m about to turn 40 and have been thinking if I should learn Perl or AWK or go with a “modern” solution for text wrangling on the command line.
The general advice here seems to be “learn Perl while young”
The general advice here seems to be “learn Perl while young”
What's the modern solution to text processing on the command line?
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.
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.
I've been disappointed to see a massive uptick in people writing a whole Python subprocess script instead of just an awk column select. They usually know awk, but Python is more familiar so they replace ten characters with a couple hundred.
It seems like fewer even want to learn a shell pipeline.
It seems like fewer even want to learn a shell pipeline.
There was actually attempts to recreate Awk inside Python. See https://github.com/alecthomas/pawk
That was bad phrasing on my part, I meant "Is there a modern alternative I should go with instead?" - I also don't know what it would be.
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.
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.
Not exactly what you're looking for, but you'd probably like looking at miller / mlr. https://github.com/johnkerl/miller
> The general advice here seems to be “learn X while young”
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
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
Perl is a super set of all things. So go with Perl.
>>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.
>>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.
On the origin of that phrase:
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.
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.
I thought it was Uncle Iroh.
Learn AWK. It's tremendously simpler than Perl, and even more omnipresent. In a week or two of study and tinkering you'll be an expert.
Awk is too specialized, specific. Perl is amazing at text processing AND also amazing at much more. The basics of perl for basic awk-like functionality is really not much to learn. Skip awk and learn something more useful.
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.
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.
awk is purpose-built, lightweight, and perfect for line-oriented tasks. Perl can do everything awk does and much more, but that power comes with complexity. If you just need text processing, awk is simpler and sufficient. If you need more than text processing, consider modern alternatives like Python that are easier to maintain and collaborate with.
I've used awk for a lot of weird shit over the last ~30 years and while I agree it's much more straightforward and convenient than Perl for most simple tasks, "expert in a week or two" is no.
Perl was 1 line vs. 100 lines in everything else, in text processing. Now it is 1 line vs. 2-3 lines that are clearer and have stricter semantics. It also has support for running oneliners straight from cli. You probably don’t want to learn it today, as it won’t make that big of a difference.
What's the 2-3 line alternative to perl you are referring to?
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.
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.
Ruby? It has perlisms and awkisms around, here's a stupid example:
echo -e "foo 1\nbar 2\nbaz 3" | ruby -n -e 'BEGIN { puts "===" }; $_ =~ /^b\S+ (.*)/ and puts "#{$_.chomp.upcase} => #{$1}"; END { puts "===" }'
I meant average line ratio, not literal one-liners, apologies for confusion.
When you're talking about doing things interactively (in a shell, either directly via a terminal or indirectly via an editor) then the constant factors matter far more than the asymptotics. This has always been perl's target for optimization. That's why it has a million obscure operators that no other language has.
In my mind Perl was the Rust of the 90s. Perl evangelists were everywhere and wanted to rewrite everything in one line of Perl.
I think you would really have needed to learn Perl in the 1990's.
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.
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.
Awk is a tiny language that you could learn in an afternoon. The real trick is remembering how to use Awk when you need it.
The things you need from Awk you can also find in Perl and learn in an afternoon. Whether you need anything else from Perl is an independent question.
Go with AWK. When your AWK code gets too complicated, that's the signal to switch to something more documentable like Python, Ruby, etc.
[deleted]
> The general advice here seems to be “learn Perl while young”
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 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 ->@*
depends on what you mean by "on the command line".
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.
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.
I learned Perl 4.036 for a university course (computational linguistics, appropriately enough) in 1996. That's ... more than half my life away.
Back in the 90’s Perl was about the only scripting platform that gave you access to host commands and info as well as the ability to connect to databases running on that host. Part of bringing up a Solaris host for Oracle always started with a visit to sunfreeware.com to get a version of Perl compatible with the latest DBI/DBD and enhanced email CPAN modules. I abused the backtick feature heavily.
Direct link to the talk:
https://www.youtube.com/watch?v=fffJnNTcLog
https://www.youtube.com/watch?v=fffJnNTcLog
That was a great talk! Notice how his entire career got launched from an internship at Tektronix. I love the bit about how he found his own troff macros in use at O'Reilly because a coworker had taken his code there years before -- and he appreciated that! One might say that the same kind of "80's hacker ethic" is what got him into trouble at Intel.
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.
[1] https://imgs.xkcd.com/comics/python.png
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.
[1] https://imgs.xkcd.com/comics/python.png
> 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.
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.
Tbh, for me it was a source of regex knowledge, in retrospect. Remove regexes from perl, what’s left?
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.
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.
$_ is not just a kid's toy.
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.
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.
It’s also where you (or your adhd colleague, or future self) introduce a subtle bug if one of your subs reads another stream and you forgot to local $_ in it. And you realize that you don’t always understand what “it” is either and that it is a bad idiom for formal systems. Isn’t worth it in the long run, especially in implicitness-ridden code that perl encourages. Write out your “line” and assign it back:
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.
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.
I use Perl for one-liners all the time -- nothing can top it there.
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...?)
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...?)
Plain perl:
open my $fh, '<', $filename or die "Couldn't open ${filename}: $!";
use File::Open qw(fopen);
...
my $fh = fopen $filename;
"my $fh" works fine if you only want to work with files you open() yourself, but what if you want to write a function that, based on some test, returns either that or the preexisting STDOUT filehandle?
sub foo {
if (whatever) {
open my $fh, ...;
return $fh;
} else {
return \*STDOUT;
}
}
Thanks. I feel certain that I tried exactly this a long time ago, and it didn't work as expected, but I may be misremembering. I'll give this a shot the next time I'm in front of a keyboard -- if it works, it will be nothing short of healing.
Slight oddities converting it into a one-liner but here's a copy and paste from a shell session running in my local WSL slice:
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=;[deleted]
>>Remove regexes from perl, what’s left?
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.
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.
Won’t nitpick, how much of what’s useful here is unique to perl? You could make a similar list for most languages and barely scratch the surface.
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.
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.
OO is the part of Perl that I grok the least. What about it makes it "far advanced" compared to, say, Java or C++ versions of OO?
https://metacpan.org/pod/Moose
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 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.
The key idea in CLOS is multi method dispatch, which Moose does not provide.
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...
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...
OO in Perl is lower level compared to Java or C++, so e.g. instead of having a class construct, you have to simulate a class - typically by binding (blessing) a data structure to a namespace. Then any functions in the namespace become methods that can be called via the data structure (object).
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.
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.
given/when are deprecated and will be removed in a future release.
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).
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 are deprecated and will be removed in a future release.
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.
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.
Consider
>> 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.
https://www.perl.com/article/on-sigils
https://perldoc.perl.org/perlreftut
% 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.
https://www.perl.com/article/on-sigils
https://perldoc.perl.org/perlreftut
yes, trailblazing.
yes, enables brevity.
yes, probably comprehensive offline std docs.
,...
https://perldoc.perl.org/perldiag should set off some alarms.
yes, enables brevity.
yes, probably comprehensive offline std docs.
,...
https://perldoc.perl.org/perldiag should set off some alarms.
My brain inadvertently changed the title to My Perl Half Life
I reference that in the talk that as I was composing the slide deck, I kept bouncing back to "My Half-life With Perl".
I came here to say: not just text processing. Thirty-odd years ago I worked on a government contract supporting users of Data General minicomputers. From time to time we needed to inspect the logs, but the log reading utility was not fast. The log format was thoroughly documented, though, and it proved to be much faster to ship a log over to a Sun box and pick it apart with Perl using unpack.
Any good reasons not to build web apps and API backends with Perl these days?
The ecosystem of PHP/Ruby/Python is miles ahead so if you need anything ranging from auth to validation, you will have to do 10 times the work.
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.
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.
The Mojolicious framework can do a lot of heavy lifting for you. It's not that hard to do interesting things while writing minimal code: https://www.mojolicious.org/
That's actually making my point, this is riduculously limited compared to the tools I mentioned.
Django's admin alone is richer in feature than this whole framework.
Django's admin alone is richer in feature than this whole framework.
Use what you are comfortable with, I write Perl backends in Mojolicious, its great.
I do. I've worked with other languages over the years but I always come back to Perl. There's a few good options for web apps/APIs.
Web frameworks:
https://www.dancer.pm
https://mojolicious.org
http://catalyst.perl.org
https://metacpan.org/pod/Kelp
https://metacpan.org/pod/Net::API::REST
Middleware:
https://plackperl.org
https://github.com/miyagawa/Starman
Some other useful stuff...
OO Frameworks:
https://zydeco.toby.ink
https://metacpan.org/pod/Moose
https://metacpan.org/pod/Moo
Type system:
https://typetiny.toby.ink
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
https://metacpan.org/pod/AnyEvent
https://metacpan.org/pod/EV
Web frameworks:
https://www.dancer.pm
https://mojolicious.org
http://catalyst.perl.org
https://metacpan.org/pod/Kelp
https://metacpan.org/pod/Net::API::REST
Middleware:
https://plackperl.org
https://github.com/miyagawa/Starman
Some other useful stuff...
OO Frameworks:
https://zydeco.toby.ink
https://metacpan.org/pod/Moose
https://metacpan.org/pod/Moo
Type system:
https://typetiny.toby.ink
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
https://metacpan.org/pod/AnyEvent
https://metacpan.org/pod/EV
Excellent comment, can’t wait to give this a look and start playing around.
It's not fashionable.
I can relate, I learned Perl when I was three and now I’m six.
I always think of Randal shwartz when I think of people saying, “I’m an X language programmer”. You don’t want to be the last guy on earth that’s the expert in a dead language.
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.