The real deal with Perl is you not only get bleeding stuff, you get all kind of obscure and rare libraries. Its not that you can't do that in Python. Its just that the culture in Python world isn't made up of people who think about those problems or even in that dimension. Its a great language for writing all variety of apps.

Perl is the og hacker's language. Python is awesome too, but its not really what Perl is.

Most of the bad rep Perl gets is because programmers who only interact with http endpoints and databases tend to not understand where else it could be useful.

Like even the regexes. They sound like a pain, until you have to do non trivial string manipulation tasks. Then you discover, regexes do it a lot better than cutting and slicing strings some 100s of times.

In the real world, the ability of a lone genius to cobble together a script in an hour is actually not that much of an edge -- it is more important for people to write something that others can understand and maintain. If you can do that in Perl, great, and if writing Perl makes you happy: also great. But beware that smug elitism turns people off, it kills communities and also tends to signal a pathological inversion of priorities. All this should be in service to people, after all

As a solo dev it is a massive advantage to use sophisticated languages and tools without worrying if the dumbest person on my team can use them. It’s a strategic advantage and I run rings around far larger companies.

You lose me with the smugness. Make no mistake, you aren't smarter or better than someone else purely by virtue of your willingness to hack on BEAM languages or smlnj or Racket or whatever languages you like. There are probably people smarter than you working in sales at $bigcorp or writing C# on Windows Server 2008 at your local utility. Novice programmers often have an instinct to rewrite systems from scratch when they should be learning how to read and understand code others have written. Similarly, I associate smugness of this form with low capacity for navigating constraints that tend to arise when solving difficult problems in the real world. The real world isn't ideal, sorry to say

I could readily believe that your stated reality is true of the majority of solo devs, but it’s not true for me or those that I know. I understand that my sampling is biased and probably not the normal experience. I don’t seek to show off for my anonymous HN account and instead wanted to say that sometimes we can have nice things and it can work out successfully.

Any success I have had in getting very boring companies to adopt nice things at all has not come from insulting people's intelligence and acting like I'm the smartest person in the room. I despise this kind of elitism that is rampant in certain technical communities. It turns people off like nothing else and serves no purpose other than to stroke your own ego -- it's pointless meanness.

My goal has not been to fix big companies for a long time, I was just musing on the rational and commented to see what other people think on the topic.

    > reduction of the worker to a fungible interchangeable cog

And every solo dev that I ever met thinks they are God's gift to the world -- "tech geniuses". Most of them are just working on their own Big Ball o' Mud, just like the rest of us working on a team.

Your sampling of solo devs could very well be biased, similarly so could my sampling. Not working on a big ball of mud is a massive perk of being solo dev. It’s my company and I’ll refactor if I want to.

Any macro/multiplier is that way. You don't miss it, until some one shows you how to do it.

In the last six months alone the scenarios where I had to call upon Perl to help slam dunk a thing insanely laborious are dozens in number.

Its just that if you don't know this, or don't know it exists, you grow up being comfortable doing manual work with comfort.

Sheer amount of times, I have seen some one spend like half a day doing things which can be done using a vim macro in like seconds is beyond counting at this point.

This is a unique combination, which I don't think will ever change. Unless of course we move away from Unixy operating systems to something entire new.

It matters little that you can generate code in an hour that would take your colleague days. It is nice for you and it provides a short lift for your team, but in the limit what matters is maintainability. Peter Hintjens writes fondly of metaprogramming and code generation, but also warns that it makes it difficult for others to work with you, and it's easy to fall into the trap of building abstractions for their own sake. The "edge" in technical work comes from seeing both the forest and the trees, and missing that technical work is in service of humans, first and foremost.

I am glad you enjoy writing Perl, and I like encountering people passionate about it in my work. But I still think there are good reasons why it's in decline, and Perl users should reflect more on that rather than assuming people aren't using it because they are dumb / not technical enough / don't think about problems as creatively or deeply.

For the first category you’re right - these days there’s not much difference between Perl vs Java vs Rust because abstractions are the same.

But where OP’s smugness comes from I totally agree when applied to the second category - there’s an ocean of a difference between using tools like Perl, awk, sed, jq, and bash to transform Unix command inputs and outputs that it really is a massive superpower. Try doing a day’s work of a Unix admin using these tips compared to writing Java to do it. Oceans I say!

But I don’t think their being a basement dweller genius as you put it is because of Perl - it’s the smugness for the same reason why BOFH Unix sysadmin got their reputation - their tools are literal superpowers compared to GUI tools etc and they can’t believe everyone doesn’t use them!

Here's the reason: these languages/tools are tactically very powerful. Tactics are immediate and decisive. Tactics are effectively tricks in the sense that if you can "spot the trick", you can -- with a tiny amount of work -- reduce a formidable problem to virtually nothing. Having a vast toolkit that facilitates such tricks is incredibly powerful and makes you appear to have superpowers to colleagues who aren't familiar with them.

But tactics are definitionally short-term. You deploy them in the weeds, or at least from the forest, (hopefully) never from the skies. Tactics aren't concerned with the long term, nor how things fit together structurally. They are not concerned with maintainability or architecture.

This is why it isn't actually that important that you can cobble together a 15 line Perl script in an hour to do something that would take any of your colleagues a week. Years from now, when you are gone and someone runs into a similar but slightly different problem, someone will find your Perl script, not understand it, and rewrite it all in Java anyway. Or assume it's too hard and give up. Maybe they will adapt your Perl script, but more likely it'll be seen as a curiosity

It sucks, because there is beauty in that approach of solving problems. As I said in another comment, I wish there were more diversity in tooling and languages. But at the same time, it's important to consider that people are fundamental. All of this is in service to that. And I personally would rather build software that people use over the long term.

I think there's a deeper truth here. Perl was notoriously difficult to make C language extensions for. Languages like Ruby and Python really took off because they had a much more approachable and useful C interpreter API which; honestly, made gluing various library APIs into the language far easier. This being the key to taking a very slow and memory hungry scripting language covering a fraction of POSIX into a useful domain extension and embedded language.

Ruby did better at the domain extension part and Python was better at the embedded language part. Perl 6 went entirely the other way. I think this was the real driver of popularity at the time. This also explains why gem and pip are so different and why pip never matured into the type of product that npm is.

XS wasn't _that_ bad once you got the hang of it; anyways, but I do remember ruby 1.6 coming out and being blown away by how improved the experience of creating distributable C modules was. The class system was flat and easy to access, you could map ruby language concepts into C almost directly, and the garbage collection system was fully accessible.

perl 6 started being discussed right around this time and I think it was clear in the early years that it wasn't going to try to compete on these grounds at all instead focusing on more abstract and complex language features.

Anyways.. even seeing your name just brings me back to that wonderful time in my life, so don't get me wrong, I loved perl, but that was my memory of the time and why I think I finally just walked away from perl entirely.

Also, same as you though - happy to see Randal’s name pop up here :)

    > beware that smug elitism turns people off

In my experience, the biggest problem with Perl is readability. Python crushes it. Without list comprehension, it is also very slow during for loops. But, no worries: Most people writing Python don't care too much about speed, or they are using C libraries, like NumPy or Pandas or SciPy. I write this as someone who wrote Perl for years, personally and professionally. Later in my career, I came into Python, and realised it was so much easier to read and maintain large code bases, compared to Perl. To be fair, much like C, it is possible to write very clear Perl, but people quickly get carried away, using insane syntax. With Python, the whole culture, from the bottom up, is about readability, simplicity, and accessibility. I think my only "gripe" about Python is there are no references like Perl, but you can fake it with single-item-lists.

Probably the lines "Its just that the culture in Python world isn't made up of people who think about those problems or even in that dimension."

and "Most of the bad rep Perl gets is because programmers who only interact with http endpoints and databases tend to not understand where else it could be useful."

I'll say this as someone who still does more than 80% of his backend work in Perl: This is not true. I wish it was.

CPAN was awesome once. Now it's mainly old. Yes, you will find obscure things which you won't find for Python. At same time, anything interfacing with modern stuff is often only 40% done in CPAN or not at all compared to the Python, PHP or JavaScript eco system. Not talking about data science stuff here, where Python gained a huge lead - simply have a look at how much support you get nowadays in CPAN for interfacing with, for example, current web api versions or interfacing with third party files like docx, pdf, excel, odt. If there's support for things at all, it is so far far far behind to what libs in other ecosystems have to offer, most of the time.

It simply shows that the crowd implementing business applications went elsewhere, so anything in that area seems stuck in the 2000 to 2010s in CPAN.

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