There's nothing obvious about how to use persistent nested variables, or how to assign key/value pairs to a blessed file handle typeglob, or the difference between calling a package subroutine as either a method or a function. The more complicated your data structure gets, the more convoluted ways you can reference it. The subtle yet different ways to do the same thing (or almost do the same thing), like int@_ vs $#_ . Does the camel book explain the magic of $VERSION? Sure it's documented, but you'd have to read every perl doc to finally get to what it is and how it works, and then somehow remember its quirks amongst the pages and pages of docs you just read.

Evaluating true and false, or just simple comparisons, can be a mystery. Heck, just figuring out what's going to be a syntax error or not depending on if a variable was declared, defined, interpolated. Or referencing a nested data structure when one of the elements doesn't exist. Even just general conventions and best practices fills its own O'Reilly book. We haven't even begun talking about regular expressions.... Then there's the autoloader, and constants, namespaces, scalar/list context, signal handling, ....

Part of the difficulty of Perl is that you can write code that works perfectly until the clearly-obvious hole you left is triggered and a fatal error occurs, and then you get to learn about the debugger. It takes years to use all the parts of Perl that have weird magic or complex, non-obvious functionality tied to them. Saying you could use it all without problems after only a few weeks is really misleading.

The fact that there is a "strict" mode at all speaks to how difficult it can be to get the language right.

It has honestly been well over a decade since I last touched Perl (not that I'd mind going back to it), so I can't say much to most of your specific criticisms.

But, evaluating true and false in expressions is tricky in a lot of languages now. PHP is notorious for it. That's why you shouldn't mix data types. Regular expressions are no longer the sole domain of the Perl hacker, they're a regular staple of JavaScript and PHP and the commandline and other utilities.

Look, here's the thing: the response to avar has pretty much been, "you guys are doing it wrong", which is a seriously uncool armchair quarterback thing to say to someone else, especially someone that's a part of something as big as booking.com. If in fact their hiring process was as unutterably broken as you seem to believe it is, wouldn't you've expected their business to collapse in a pile of inscrutable bugs by now?

I'll readily agree that there's a vast difference between a coder in any particular language, and an expert in that language. That's why the experts get to define the language conventions used by a business, and the coders get to follow them. That's why there's testing and debugging and staging.

I try to assume least level of incompetence in other people on HN. Maybe instead of declaring things about their code base that you have no actual knowledge of ("There's no way anyone can just pick up Perl and write good Perl code without a dozen best practice errors. Hiring someone who doesn't know Perl very well basically guarantees a high rate of bugs in your codebase."), you could instead ask, "How do you guys handle training the guys that aren't very familiar with Perl quirks like int@_ vs $#_?"

I've worked at lots of places with really lame hiring and people just get stuff done. They also get stuff done with lots of bugs, which costs the company time and thus money. So inefficient hiring process does not mean your business folds, but it does mean your business may suffer.

And i'm not assuming any level of anything. If you learned spanish in Spain, you can't just go to Mexico or Venezuela or Argentina and pick up the local dialects, because there's different grammar and vocabulary and pronunciation you won't know until you run into it. Trying to write a paper in those countries after only using their dialect for a few weeks will land you with mistakes. I don't think this is a controversial thing to say. (And this is assuming you're picking up a very similar language; trying to go from Spanish to Portuguese would be nearly impossible in just a few weeks)

Grumble, don't talk about e.g. JavaScript regexps. :-(

>>which is a seriously uncool armchair quarterback thing to say

Imho, you read too much into the discussion. Everyone knows that Booking.com must be doing a lot of things right for their particular problem set and situation. It is a high profile place that attract good talent. (I am hardly alone in assuming they aren't too stupid to listen to Ovid et al.) Their situation is unusual and the resulting specific differences in methods will be questioned, because of their high profile.