Larry Wall is a linguist first, and the design of Perl's syntax reflects that. So I can totally buy taste being more important than technical foundation, in the same way good graphic design is done.
These expressions with the conditionals on the end are supposed to reflect English phrasing. English isn't strict about the order of parts of speech; you can mix them around to change the emphasis. These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent, the way one programmer might explain the logic to another programmer.
> These expressions with the conditionals on the end are supposed to reflect English phrasing.
But nobody's ever explained why that would be a good thing to do. We say things like 'you can read it out loud and it sounds like English', without ever arguing why this is a good thing.
Do most programmers even have English as a first language?
I'm not sure aspiring to be like natural languages actually has any merit. I think we should aspire to precision and clarity. Natural languages rarely have those qualities.
From DougWebb, explaining why this would be a good thing to do.
>> These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent.
We can achieve perfect precision and clarity by naming all of our variables x1, x2, x3, x4, etc. But it's better to give descriptive variable names because it helps us and anyone else reading the code understand what it does. This sort of expression is similar.
I can't see any argument in there. 'meant to express programmer intent'? What does that mean? Basing programming languages on mathematical notation or something else would also of course be 'meant to express programmer intent'.
Why are natural languages a better foundation for programming languages than, for example, maths notation or calculi? Everyone in the Perl community seems to think they just intuitively know it is, but can't explain why.
When you're speaking to another programmer, explaining what a bit of your code is trying to do, do you speak in mathematical notation? I doubt it. I don't think even mathematicians do that.
If you want a well-expressed explaination for why Perl's approach is a good idea, you should read what Larry Wall has written about it. All I can really say is that it worked really well for me and my team for many years. We rarely misunderstood each other's intent, even though our code reviews were mostly just reading commit diffs.
Think of it as a commenting or documentation system that's also interpreted by the language. Comments that can never get out of date.
If you think that human-readable comments and documentation are not useful... then I'm not going to try to convince you that you would benefit from perl's syntactic flexibility. But surely you recognize that there are some people that like documentation, useful comments, and informative variable names.
It's actually "if x { y }" in Perl rather than "if x then y".
This favours blocks of multiple expressions whereas "y if x" is good for a simple single expression.
A lot of the Perl branching and looping directives provide both methods so you can choose what you prefer.
Having both ways is great for the Perl one-liners :
cat file | perl -e 'while (<>) {next if /^SKIP /; print if /<fancy regex>/;}'
If all someone wants to express to a reader is literally `if x then y` then `y if x` doesn't really help.
But we typically don't write utterly trivial one-liners with single letter names for conditions and actions.
In actual programming there are times when it's more like a series of lines, each of which is something akin to `if some-expression-that's-so-much-longer-than-a-single-letter-that-you-start-to-consider-factoring-it-out-in-to-another-variable-or-function then some-function-or-flow-control`.
And when that happens there are times where by far the most important thing a writer wants to first bring to the attention of a reader (eg themselves, later) is some-function-or-flow-control.
Sticking with made-up examples for a moment, there's:
if long-complex-conditional----that-you-might-start-to-read-thru-in-an-attempt-to-understand-the-code-you're-reading---is-true then blow-rocket-up
vs
blow-rocket-up if long-complex-conditional----that-you-don't-need-to-read-and-understand-to-understand-that-the-rocket-will-blow-up-if-it's-true----is-true
Or it takes me I estimate less than a second to know the gist of the overall control flow of this fragment from a recent Advent of Code entry[1]:
next unless (() = /[aeiou]/g) >= 3;
next unless /(.)\1/;
next if /ab|cd|pq|xy/;
$count++;
I can immediately see that it increments `$count` unless it bails out of the containing loop (`next`s) due to any of several (complicated looking) conditions.
In contrast, it might well take me more than a second to figure that out if they'd written:
unless (() = /[aeiou]/g) >= 3 { next } ;
unless /(.)\1/ { next };
if /ab|cd|pq|xy/ { next};
$count++;
While these examples are pretty weak, I have hope that they might at least give you pause for thought. If you don't see anything going on here worth even thinking about, or more importantly seriously reflecting on, well, at least I tried. And if you're a trained linguist and/or able to quote science to refute what other scientists are finding in recent studies[2], please quote away. :)
These expressions with the conditionals on the end are supposed to reflect English phrasing. English isn't strict about the order of parts of speech; you can mix them around to change the emphasis. These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent, the way one programmer might explain the logic to another programmer.