I'd chalk that up to there being relatively little cross-section between "Perl users" and "HN visitors". Sure, some of us do exist, but for a lot of the current-gen programmers, suggesting the use of Perl might as well be equivalent to suggesting the use of Fortran or COBOL, and for good reason: there are plenty of perfectly good programming languages out there from which to choose, many of which include PCRE (Perl's regexes being a huge selling point for using Perl).

I'm willing to bet that quite a few of the naysayers even on this thread haven't seen much Perl beyond perhaps some deliberately-unreadable code-golf-style Perl one-liners. Yeah, those are fun to write (and only slightly less fun to decipher), but real in-the-wild Perl is usually surprisingly readable.

I've done a lot of work on older systems that don't include Python or anything trendy, so Perl was my go-to language for a long time, so that I could avoid a mess of different shell languages and such. I always took pride in writing readable Perl that someone didn't have to be an expert in order to follow.

It's a very obedient language, in the shoot-yourself-in-the-foot kind of way. I still use it as a convenient way to access PCRE in short scripts, but the longer it is, the more likely I am to switch to Python.

Perl gives you plenty of rope to hang yourself with. That isn't a good thing in any language.

Sure, but it ain't a "bad thing", either. It's just a thing about Perl, neither good nor bad. It's pretty easy to avoid self-asphyxiation in Perl, and that rope can be used to tie all sorts of knots other than just nooses.

It is a bad thing, since while it usually is easy to avoid self-asphyxiation, when given enough rope to hang themselves people invariably use it.

When I've had to read/bugfix/adapt Perl code, most of the time all the bad things people say about Perl were there, that's just the way how the world works, that's how people are.

The same applies for other languages. Get a task for maintaining random C code, you will have to fix memory handling problems; get a task for maintaining random JavaEJB code and you will invariably see unreasonable extra layers of indirection added; get a task for maintaining random Perl code, and you will have readability problems.

For maintainability, you want something that prevents people from tying all sorts of interesting knots whenever standard, idiomatic solutions can be used.

I'd rather have enough rope to hang myself than not enough rope to climb a mountain.

"When I've had to read/bugfix/adapt Perl code, most of the time all the bad things people say about Perl were there, that's just the way how the world works, that's how people are."

This might very well be confirmation bias. If code needs fixed, it's unlikely to be high quality to begin with. The similar examples for other languages demonstrate this effect.

Really, all languages have their strengths and weaknesses. In Perl's case, its strengths also happen to be its weaknesses. :)

"For maintainability, you want something that prevents people from tying all sorts of interesting knots whenever standard, idiomatic solutions can be used."

True, but when standard, idiomatic solutions don't exist for the problem you're trying to solve, being able to tie interesting knots is a lot better than being totally out of luck.

One of Perl's underlying philosophies is "Easy things should be easy; hard things should be possible". There are some things that really could and should be easier (FFI being among them: without installing third-party packages, the "recommended" way is to splay open Perl and start fiddling with its C internals, which is absolutely absurd; something like FFI::Platypus really ought to be included by default), but Perl has an "anything is possible" mentality that is invaluable for solving hard problems.