So I basically agree with you & jschwartzi. But to expand or reinforce my original point, it is very clear there is a substantial contingent of programmers who do not. While of course in my own opinion, my own opinion is correct (duh), at a more global level, or maybe in a more academic sense, I'm open to the possibility that I'm wrong. I've already flopped on that matter once in my career and I reserve the right to be convinced by another language that I'm wrong now, too.

You don't have to be "wrong". You just have to be not exactly the same as everybody else. And of course, nobody is exactly the same as everybody else, therefore there is not possible for there to be such a thing as The One Perfect Language. The right tool for the job; but also the right tool for the workman.

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.

>"There should be one — and preferably only one — obvious way to do it."

Which Python manages to break all the time. How many ways are there to format a string again?