During his talk Netaniel complains about the Perl Community, which he assumes is being represented by the people on perlmonks.org, responding to his talk last year aggressively, personally and with trolling. Well, this comment will be personal as well and surely offending.
Let's be clear first: the problems pointed out by Netaniel during his second talk are indeed real in a sense. But they are not new, nor are they perl specific. At least they are well known for years (see the gist linked above for more details). The problem I'm seeing with this talk is the tone.
You see, there's criticism and there's rants. Netaniel's talk is a rant. And it's not justified. Obviously he REALLY hates perl. He makes fun of it, he shouts at it, he even insults it. However, we're talking about a fucking programming language, not a human being, or an organisation or the like. This boy stands on the stage and behaves like a five year old shouting at his non-functioning Lego construction: "You Moron!".
My impression of this talk (and thus Netaniel) is worse than the last one. It's funny if you don't have a clue but insults the intelligence of the initiated.
Dear Netaniel: "Stop using Perl!" is a childish, ridiculous and unrealistic demand. And your "arguments" aren't getting the more valid the louder you shout them. Therefore, let me explain to you how the real world looks like:
There are lots of computers running these days (not counting PCs, notebooks, tablets or phones). The majority of them is not connected to the internet. These are headless servers running unattended most of the time (just to make sure you understand what I'm talking about since you're a windows user: headless in this context means "no GUI", just a console). Such systems are operated by system administrators, labeled as "DevOps" these days.
Administrators are responsible for lots of systems, hundreds or even thousands of servers. Many of such servers are legacy systems running legacy operating systems and legacy software. Sometimes it's not possible to update them, sometimes it's not allowed, sometimes there's no developer for the particular software running on it left in the company. So they keep running. And running, and running, and running.
Administrators are a lazy species. If they ever watch themselfes entering the same cascade of commands twice they put them into an shell alias. And if it grows so much that it doesn't fit into an alias, they put it into a shell function. Sometimes such a function grows and grows so much that it doesn't make any sense any more to maintain it as a shell function in .bashrc or something. So, the administrator puts the function into a script.
The script grows further and sometimes reaches a point where it is a pain in the ass to continue to develop it as a shell script. The administrator decides to go to the next level and rewrite the thing with something more powerful and flexible than a shell script. In essence he wants to convert the script from a beast into an elegant lady.
Now, Netaniel, remember what I told you earlier about legacy systems. You cannot install node.js on an AIX system of the past decade. You're not allowed to install Go on a mainframe. There's no modern ruby package for that ancient Sun machine. But there's Perl.
Let me repeat: but there's Perl!
Perl is part of the base installation of most operating systems of relevance (that is: not Windows, Netaniel, sorry) for decades. A well crafted perl script can be deployed over dozens of different platforms doing the same simple thing, stable, portable and maintainable. Sometimes Python can be used instead. If all servers have python. Sometimes even ruby might be used. But the more heterogeneous a network gets and the more legacy systems it contains the higher the probability that you will be stuck with Perl.
The reason is simple: Perl itself is a legacy system. It was born out of system administration, designed by system administrators just to make their live easier. Not necessarily yours, that is.
Of course, since its inception, people have done things with Perl beyond imagination. The even wrote CGI scripts, replaced them with application servers which they then replaced with content management systems. And all those dirty features built into Perl to make administrators happy are still there, waiting to be exploited by Kids like yourself.
That's the reason thousands of developers all over the world implemented better systems like Mojolicious, because we already know of those features. Your demo code will not work if you just put an "use strict" in there. And we urge people to do so since years after years. The fact that you don't seem to know it, shows how unfamiliar you are with perl. And the fact that you don't seem to know that flexibility with variables is not in any way specific to Perl, shows you never developed anything. Someone in the monk thread (linked above) from last year pointed out that he couldn't find anything you ever developed. This didn't change 2015: there's still nothing to find made by you. Even your Github account with which you responded to the gist post linked above is fresh and has not a single repository or contribution.
Let me say it bluntly: Don't diskuss battle tactics with us unless you bled with us!
New perl module Data::Interactive::Inspect and dbmdeep
Re: The Perl Jam: Exploiting a 20 Year-old Vulnerability [31c3]
Besser spät als nie :)
How to reinvent the fucking wheel