Obviously what's "readable" is not constrained to what some people find readable, but to what most people do.
That's hardly obvious to me at all. Leaving outside language syntax debates, the important readability concerns of code I deal with tend to include:
* the business domain
* the ecosystem of existing code in the organization
* the experience level of other developers
* coding standards and guidelines
* deployment and maintenance concerns
* the organizing concepts, architecture, and metaphors of the code in the small and large
* the context of where the code lives -- is it a one-off, is it structural code to get from one design to another, is it long-term code that has to meet certain criteria to be maintained for years
A random piece of code waved in front of a random person tells me nothing of interest with regard to those criteria.
So even if you have no trouble using Perl and writing "readable" code that you can read yourself, that doesn't mean rest of the people can read what you wrote.
Seems like that argument has moved the goalposts from "most people" to "most people who use the language", and it's still not clear why that's an interesting barometer.
Even acknowledging that this is a thought experiment, what does the ability of J. Random Perl Hacker to grok a piece of random code from a domain and context with which he or she may not be familiar indicate? Surely a one-bit "is this readable" test has lost so much signal from the interesting criteria that it means very little!
I have no idea what your run-on sentence is trying to say, and don't want to bother trying to figure out what you're trying to say either. And this is my point. Being too "expressive" makes it hard to share ideas. That's why they teach you to not use run-on sentences at school, but people still use them sometimes because it's easy to get carried away.
In a normal human language like English this flexibility and expressiveness is not always a bad thing since it allows all forms of art, but programing languages are not meant for avant garde navel gazing. They are for getting stuff done. And I don't want any run on sentences on my application.
However, it is possible to right miserably bad code in a variety of languages. The Perl that one finds (for example) on CPAN is generally straightforward and understandable. One can write lucid and powerful Perl.
And I have no trouble understanding any of the sentences of the parent comment. Is your complaint that the verb "indicate" falls after the clause it refers to?
This may subvert your point about the effort "most programmers" put into reading code. I think it's a superficial criticism.
Obviously because one's code has to be maintained by other people.
Plus, if anything, going from "most people" to "most people who use the language" has moved the goalposts closer, not moved them apart (which is what people complain what one "moves the goalposts").
Certainly, but that makes the criteria in my post much more interesting. The people in the new set are more likely to understand the features of Perl and how to look them up in the documentation or use formatting/linting tools to de-obfuscate code.
Unless the argument is that Perl as a language has some features which make it impossible for anyone to decipher, the context around any piece of code seems important to understanding it.
Personally, I find most of the criticism misguided. I can see why many people collaborating might prefer the comparative straight-jacket of Python to coming up with their rigorous style guidelines. Perl just doesn't dictate, and that comes with a lot of advantages and disadvantages. I might go as far as to say that on average, perl makes a bad trade-off for teams, as having a language with a narrower philosophy (Ruby aiming for pure OO, Python aiming for readability) relieves you of making and enforcing those decisions. However, I do enjoy programming perl when working alone, as perl lets you do the right thing, whatever you think it is.