Re^4: 5.40 released

[Anonymous Monk]

I guess you're right about being off topic. Sorry I was just trying to be informative. Was triggered by reading that trinary (sic) is hard to read after seeing a multiple parameter loop in perl that was supposed to be easy to read... 🤷

$ternary = $can
? be_really_easy
: to_read_btw;

[Danny]

No worries. I'm a big fan of ternary expressions myself. However, I don't get all the hate for for(my $i = 0; $i < 10; $i++). Just because it's not unique to perl doesn't it make it non-perl.

[ikegami]

I don't get all the hate for for(my $i = 0; $i < 10; $i++)

It's extremely hard to read and error prone. for my $i ( 0 .. 9 ) is so much clearer. This is true for this trivial case, and even more so for anything more complex. It's also a lot slower, but that's a secondary considering by far.

[Anonymous Monk]

I don't get all the hate for for(my $i = 0; $i < 10; $i++). Just because it's not unique to perl doesn't it make it non-perl.

(my $i = 0; $i < 10; $i++)

This rarely makes sense in Perl. There's an entire freakin program unnecessarily stuffed up in those parenthesis! First we have to declare and initialize a variable, then we set a condition on the operation, and finally we iterate. It's pretty cool and all but compared to what perl can do it looks like a messy hack in some language that lacks implicit variables. I think that's cargo cult perl and may contribute to several bad reputations related to readability, line noise and our beloved sigils.

(my $i = 0; $i < 10; $i++)

vs

(0 .. 9)

The Perl Way eliminates the unnecessary 9 symbols ($$$;;++=<), 5 spaces, 5 letters and a variable because the range operator sets our condition and gives us an implicit iterating iterator for free! Of course sometimes an explicit variable is required to avoid clobbering an implicit inner construct:

my $i (0 .. 9)

I do understand Cavac's desire to keep codebases consistent by having Perl constructs emulate C and Javascript, and it's wonderful that Perl can emulate them with ease (ironically by adding "line noise"), while they can't hope to emulate the elegant simplicity of implicit Perl. Anyway that's why we hate it :-)

[ikegami]

The reason it's so hard to read and error-prone isn't the number of sigils in my opinion; it's the amount that's variable.

These parts are fixed:

for my ___ ( ___ .. ___ )  # Perl

for ( ___ ; ___ ; ___ )    # C

We can quickly identify these as counting loops, and we can quickly identify and locate the parts that define the loop. (Well, the number of sigils in the C version does make this harder, so the number of sigils is a factor, but I believe this to be a secondary factor.)

So what's left? In the Perl version, we have $i, 0 and 9. Clearly unbeatable for clarity in this trivial case. But it supports more complex cases well too.

In the C version, we have my $i = 0, $i < 10 and $i++. That's 9 tokens (when counting $i as one)!!! And all of them could vary. Is < used or <=? Maybe neither... Is my used? Is the same var used throughout? etc etc etc etc There are so many variations that the whole must be analyzed each time it's encountered.

Most of the time, the loops takes on the following shape:

for ( my ___ = ___ ; $same < ___ ; ++$same )

But variations occur too often to assume the loop takes on this shape. And it's not always easy to spot if a variation is used at glance. But we make this assumption anyway, and that's when mistakes happen. This is why it's also error-prone.

This is the same reason we use subs. We sacrifice flexibility, but we gain readability and reliability.