The general joke about Perl is that it's "write-only". When I wrote POPFile I spent a lot of time ensuring that the code was readable and maintainable. I hope it's still understandable: https://github.com/jgrahamc/popfile/blob/trunk/engine/Classi...
Compare that to PHP where theres generally one way to do something right.
I worked on (and modernized) a distributed ETL system all in Perl some time ago, and applying the long-codified ideals of Modern Perl made it one of the cleanest codebases I've ever worked in.
I see lots of Java that's written in a simple and direct manner, but that has no documentation/comments and where it's a pain to find the execution flow in between so many classes and layers (especially when there's dependency injection).
If it were just dependency injection it would be one thing but when you have all the opaque behavior that comes with a framework like Spring you get a bunch of spooky action at a distance code that can't be followed simply by traversing the call stack.
Comments don't compile, so the only documentation of what code is doing guaranteed to be correct is the code itself.
Really like comments for providing edge cases and information that can't be found by reading and understanding the code.
You can write some absurdly powerful, really terse programs that make absolutely no fucking sense to anyone else.
Some people see this as a point of pride - Perl golfing etc.
My point is that there are extremes here that are worth considering: and Perl is on the bad side of any exchange involving the question of readability. The community doesn't help, either: they're as bad as the Rust Evangelism Strike Force, but in different ways.
Who do you think RESF learned their ropes from? ;-)
This article has aged pretty well: https://www.perl.com/pub/2000/12/advocacy.html/
A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes a huge monolithic monstrosity by creating their own ORM and object model with almost zero documentation in or out of the code and hoo boy, that is not going to be a fun time 10 years later when basically nothing has changed because no-one has the time or energy to parse out what they've "crafted".
I agree. Perhaps Perl culture encouraged that kinds of development. But I've a seen number of monstrosities in other, better known languages that are "crafted" that way as well. I'm currently working with a large commercial product in C that would undoubtedly be easier for the 50-strong team of devs to work with if it was written in Perl (though they would still complain), and ironically it would probably run faster in Perl too (and be much more secure).
I don't think the problem is the language really, as Perl can be written in a modular and fairly clean way too (compared with many other languages) if the developers are minded to. I think it's the culture in which those large projects were developed. Or rather, the lack of software engineering culture for long-term maintanence, and a disinclination to use frameworks and patterns that would be familiar to new developers coming in later, especially from other environments. It may be that Perl's rise and fall was a product of its timing relative to software-at-scale culture as much as anything.
Despite its origins as a glue language, Perl 5 is a Lisp-like once you see past the syntax. Perhaps that's part of its problem: Lisp encourages creative and unique approaches to large projects too, and also isn't widely used any more.
Definitely you can keep your Perl under control with a strict(ish) culture but that tends to be the kind of culture Perl acolytes traditionally chafe against. I do somewhat blame the "there's more than one way to do it" Perl culture - that definitely encourages a, uh, "cowboy" approach to development that I've seen a lot in Perl houses (compared with, e.g., the Go houses that I now deal with because Go has a definite "one way to do it" culture.)
But yeah, pretty much any language can be twisted into a monstrosity if you let the devs run wild.
Any time I've ever tried to look into <insert random open source C project>, I typically find the most esoteric and tersely named functions inhumanly imaginable. Variables like gt, pn, r8, _on, etc. I mean terse to a point of cruelty. And yet these projects often have hundreds of contributors who are happy to gloss over said unreadability, or at least forgive it more than Perl.
Oh, and you're fully expected to speak their argot fluently, of course, otherwise you're a castaway to be thrown stones at.
Maintaining that in house codebase that used it was such a pain. I had to help keep that ORM up to date with the new data models after the acquisition.
I can still _read_ Perl code (and used to read PerlMonks for the koans), but it is definitely an acquired taste when whomever wrote it decided to golf a bit to save typing or do some clever re-use.
I love Perl, but that's the part I don't like. If you, for example, have to parse a very deeply nested piece of JSON, you're very quickly into that weak spot. Lots of crazy sigils, braces, etc...all mushed together. Worse if you're having to use refs, globs, etc.
What you're running into is insufficient modeling of the problem, not a deficiency unique to any language.