Hacker News Reader

> 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.

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.

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.

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

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.

One liners. I dropped ruby when it could not express various one liners as well as perl can.

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

>>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.

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.

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!

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.

> 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.

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 :)

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.

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.

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.

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.

    > 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.

    > beware that smug elitism turns people off

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.

> 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."

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.

    > Node/NPM definitely is on-par with CPAN. But pip isn't even close.

Can you explain why Python pip isn't close to CPAN? I could always find what I needed.

> 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’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.

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.