[kamaal]

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

[stouset]

The superpower here is a scripting language, not Perl specifically.

[kamaal]

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.

[canvascritic]

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.

[alfiedotwtf]

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!

[canvascritic]

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.