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.
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.
> 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.
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 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.
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.
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.
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.
> 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.*
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.
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.
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.
> 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 ->@*
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.
There's -p too, -0777 works for slurp mode, throw in -rjson to get battery-included pretty_generate, interpolation can be nicer, but $_ is not implicitly used so it can get a bit more verbose than Perl.
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 is one of those power tools(as recommended in Let Over Lambda, together with vim and Lisp), if you learn it well enough to be good at it, and early enough in your career- You really have a mad productivity work horse. Its really one of those things which save tons of time and effort. A bit like O(1) hack of the productivity world.
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.
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?
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.
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.
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
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.
> reduction of the worker to a fungible interchangeable cog
I see this trope a lot on HN, and I don't understand it. All of the highest skilled developers that I have met are the quickest to adapt to new projects or technologies. To me, they look like 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.
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
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 don't know what caused this reaction. Was the OP being smug or elite? I did not read it that way. If anything, in my experience, C++ and Rust folks are way more smug/elite compared to Perl hackers.
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."
>>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.
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.
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.
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.
> 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.
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.
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.
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 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...?)
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.
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.
My then-girlfriend and I, kicking it O'Reilly style, 1996: https://i.imgur.com/PPmZs9P.jpeg
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
A procedural/imperative ORM, quite neat actually
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.
Any good reasons not to build web apps and API backends with Perl these days?
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 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
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.
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.
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.
> 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 ->@*
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.
Ruby? It has perlisms and awkisms around, here's a stupid example:
There's -p too, -0777 works for slurp mode, throw in -rjson to get battery-included pretty_generate, interpolation can be nicer, but $_ is not implicitly used so it can get a bit more verbose than Perl.I meant average line ratio, not literal one-liners, apologies for confusion.
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.
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 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.
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.
I thought it was Uncle Iroh.
Go with AWK. When your AWK code gets too complicated, that's the signal to switch to something more documentable like Python, Ruby, etc.
I learned Perl 4.036 for a university course (computational linguistics, appropriately enough) in 1996. That's ... more than half my life away.
Direct link to the talk:
https://www.youtube.com/watch?v=fffJnNTcLog
Perl is one of those power tools(as recommended in Let Over Lambda, together with vim and Lisp), if you learn it well enough to be good at it, and early enough in your career- You really have a mad productivity work horse. Its really one of those things which save tons of time and effort. A bit like O(1) hack of the productivity world.
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.
> 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 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?
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.
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.
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!
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.
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
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.
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.
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
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.
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."
>>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.
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.
> 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.
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.
> 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.
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.
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.
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 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.
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.
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.
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.
yes, trailblazing.
yes, enables brevity.
yes, probably comprehensive offline std docs.
,...
https://perldoc.perl.org/perldiag should set off some alarms.
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...?)
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.
I can relate, I learned Perl when I was three and now I’m six.