Still about the best duct-tape
It's easy to complain about perl, to be sure, as sinecure-minded hacks can use the freedom to write code only they can understand. Job security for jerks.
Or you can do as I do and write it such that what's going on is utterly obvious - the freedom swings both ways.
When I started this game - ASM on a PDP-8, then on Z80 and X86, finally dragged into C, the C++ (which I now like, at least without the far-worse-than-perl new crap), it often made sense to roll your own. You knew what your standalone application needed and wanted to accomplish. A flat file with a couple special functions might beat a database - and computers were limited enough that such things would fit, where the "use big things off the shelf" model would require a special machine to even run. It was totally worth it to create your own special version of the obvious services, math libraries, display interfaces, you name it.
This is no longer true.
Why would you write a web server when there's Apache, or NGINX (which runs sweetly on a raspberrry pi!)?
Without getting into the which is best war - ditto MySQL, PostGress and a number of others down to SQLite.
Plotting? Gnuplot and a few others come to mind.
Display interfaces - there are plenty of write-once, debug-everywhere interfaces to system libraries now for almost any language you like. Not completely opsys independent, but the GUI if an app has one, is simplified as a matter of style these days.
As far as handling anything tricky - see CPAN - there's an app for that already, no need to write up something - and they are _well_ _documented_.
No other language matches that for sheer number and variety.
By extension, few are writing their own neural net libraries, other than as adapter for existing ones. And duct-tape code to feed in that "big data" from some database.
Name your new killer app, and all the big difficult pieces exist already, and almost all are free.
So what's needed is a duct-tape language that makes sticking all this existing functionality together in new ways with a bit of adapting.
Um, perl was designed for just that, and is still at least in the running for the best at it. You don't have to write line noise, I never do.
I have large realtime control, data acquisition, and analysis systems using perl to stick together some of the things listed above, they work flawlessly in my physics lab, run on all manner of machines with no changes.. and they were easy to write, and are easy to maintain - even though one machine might be mostly data aq with some control, another few might be video cameras sharing streams to the database via the opsys sharing utilities - some are even raspberry pies, some are PCs -
Perl makes this all easy. What is an add-on in most languages - the ability to talk outside that runtime's box - is natural in perl. It's why it was created.
I'm glad Larry approves the renaming of that new language. It's almost nothing like perl, just close enough to make you think you know something, but nope, you don't. Like perl, at inception, it's too slow for most of what perl5 is now plenty fast for. It does preserve the ability to write either obvious code, or stuff so weird no one can figure it out. Raku has things going on under the hood (deep magic) that can take till the heat death of the universe to run or eat all of the system ram in about 1-2 words of code. NIce for learning math theory (rationals, series, built in toys) - but for real work? Maybe someday. Meanwhile I'll use languages that get my jobs done.
Damian Conway's demo that you can write a complete Turing machine that will run a sort in the C++ templating language without actually creating a single line of C++ code tells it all. Go look at some modern C++ and tell me it's not far more obfuscated than perl!
Biting the hand that feeds IT
