These days, people that aren't novices tend program much more clearly in my experience, and there's style guidelines and code linters to take up the slack. It's not like other languages never have to deal with people writing odd or unintelligible code either, there's a reason why style standards are a big thing in many places. Here's an example of a module I use that I just looked up. It's fairly terse in parts (but it's a module, so I hold it to a different standard than my own code), but I would expect anyone familiar with perl would have zero trouble determining what's going on in here, and a lot of code bases will be a little more verbose or use more white space to error on the side of caution and help people process what they are seeing easier.[1]

1: https://metacpan.org/release/Path-Tiny/source/lib/Path/Tiny....

Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha.

Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).

That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio.

I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.

‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.

There's nothing inherent about Perl that causes people to use $z instead of $somethingDescriptive. And regexes have for quite some time allowed for insignificant whitespace to comment things in detail.

If you comment your regexes and use decent variable names, you solve 98% of the readability problems of Perl, and both of those could be enforced with a linter. But as I said, a lot of the problems come from one liners being slowly expanded. Using single letter var names for anything is fine in a one liner, but not good for long term program legibility or maintance in any language.