alabamenhu

90% of Perl's line noise comes from using short cute variable names and trying to cram way too much into way too compressed regexes.

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.

I think so. I regularly use JS and Java in daily life and used to use a whole host other languages in the past.

Perl 6 is actually a joy to code in, as weird as that sounds. It's fairly straightforward to begin using, but the deeper I go the more I see the huge benefit to its long development which was mainly in spec-writing. The two killer features (for my work, at least) have been the grammars (a sort of regex on steroids that is actually readable) and the multiparadigm approach. I mean you can do functional coding with Javascript sort of, but you end up with a lot of extra line noise compared to P6 where it was contempalted from the beginning (and multisubs clear things up even more). All the typical paradigms are integrated fairly seamlessly to let you choose the best tool for the job for whatever block of coding you're working on.

The idea that there's only one way implies that code context means nothing.

For example, if you have a simple function that kicks backed cached values:

  sub foo ($bar) {
    if %cache{$bar}.defined {
      return %cache{$bar}
    }
  }

Is an absolutely correct way of doing things. But it's messier then using a postfix:

  sub foo ($bar) {
    return %cache{$bar} if %cache{$bar}.defined
  }

Or simplifying:

  sub foo ($bar) {
    return $_ with %cache{$bar}
  }

While it's true that

  sub foo ($bar) {
    .return with %cache{$bar}
  }

is possible, I don't tend to use it too much because the dot syntax isn't as pretty with postfixes ha. But each of these options has a place where it is the better option, but none of them is universally the one and only best option. Nested ifs with multiple statements may go better with the first one, but if several conditionals have similar elements and are simple statements it might behoove to line them up with whitespace. But the placement of return right at the outset (as opposed to nestled in an if statement) to me makes it clear the return value is a gate-keeper of sorts. Ditto for using 'die if [cond]' which much more in your face then 'if [cond] {die}'.

All of the above code is readable though. Of course, a functional approach could be just as valid and readable, and clear:

  multi sub foo ($bar where %cache{$bar}.defined) 

{ %cache{$bar} } multi sub foo ($bar) { ... }

Or taking advantage of traits:

  sub foo ($bar) is cached { ... }

Almost inevitably the unreadable code is where someone is trying intentionally to be cute and write unreadable code. But that can be done in languages like C too, or with any language that allows single letter variables.

That's a problem with the people who wrote the script, though, not the language itself.

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).