Or at least, purportedly perl according to the wikipedia page I retrieved
it from (which notes the author is unknown - if you are they and would prefer
I not reproduce this, please tell me). It doesn't seem to -quite- compile
here but I'm going to handwave that away on grounds of irrelevance.

Here's my point. Or at least the start of it: perl can (could?) parse
code like that. Your brain quite happily parsed the title of this post before
going "wtf? that makes no actual sense". There is a pattern here.

The annoying thing about natural language, especially IME english, is that
it gives you a lot of rope. It's flexible, contextual and you can generally
interpret even very odd looking sentences to some extent. Including the
sort-of-a-sentence I used for a title. The fact it could almost be mistaken
for a sentence (and that a computer doing only grammar recognition almost
certainly would do so) doesn't make it good english. The advantage of having
that much rope is that it buys us the opportunity to be expressive.

By expressive here I think I'm trying to mean "lets us express the letter
of the thing in a way that also implies the spirit of the thing". So ... to
my mind Modern Perl is aiming to
express a pretty similar thing to Enlightened Perl in terms of the letter of it - modern, sensible practices
in code. However, the former is merely a clinical description whereas the
latter implies a sense of forward motion and association with a mindset, a
fusion of art and science that moved the entire world forward. It tries to
capture an understanding of why you should care, why you should want to be
part of this, in a way that "modern" just doesn't.

Which brings us to: expressiveness is important. It allows you to show a
lot more information than a clinical language can - try conveying emotional
undercurrents in lojban, for example. So, in perl one can write -

- and the code that each compiles into will be equivalent (and depending on
how much the optimiser loves you today, quite possibly run-time identical).

However, all three -express- something different, at least to the skimming
eye trying to get the shape of the thing before delving into the details. The
first one makes the call to the routine most obvious, the second the exception
and the third the structure of the conditional. Effectively, the choice of
syntax to produce the given semantics is providing emphasis to the code in
the eye of the reader.

So, for example, I'd tend to use the first one to
express wanting an action to happen and incidentally needing to bail out if
it goes wrong -

open my $file, '', $filename
or die "Error opening ${filename}: $!";

- and by putting the or onto a second line, emphasise its being a subsidiary
clause that's not crucial to understanding of the overall purpose of the
routine.

The second, on the other hand, is preferred for cases where the
primary purpose it to throw a useful and clear exception if required and the
test is merely there as part of that purpose -

die "Don't have permission to read ${filename}"
unless -r $filename;

For such simple cases, I almost certainly wouldn't use the block form - the
point at which that becomes advantageous is where there's more complexity to
the test and the additional syntactic structure becomes useful as a form of
delineation. So, perhaps:

Rewriting this into either of the other two forms would require either a
block or some monstrosity like chained && calls or comma operator abuse - and
this way the seeking eye can see the unless at the head of the block and know
that this is the "exception to the rule" branch - and if that's not what
they're currently looking for skip their eye to the end of the block via the
indentation and bracing.

Linguistic expression can provide implicit semantic
weighting to otherwise identical wording, and this is an important tool in the
continuing fight to make programs that are easy for another human to come along
and understand - the computer might not care what you mean so long as doing
what you say produces the right answer, but to a maintenance programmer the
purpose of a piece of code is often far more important to figure out than the
detailed mechanics, and any tool we can provide to make it easier to do so can
only be a good thing.