[chombier]

One can write pretty much the same code in python/c++11/whatnot and it also feels quite natural to read:

   for number in numbers:
       if number <= 10: continue
       work(number)

Do you have a better example where the Perl syntax would shine?

[raiph]

You have clearly been able to read and translate the GP's code and confidently assert you've written "pretty much the same code".

> Do you have a better example where the Perl syntax would shine?

Unless you have "a ton of knowledge about Perl" your reply shows that it was a perfect example in response to the GGP.

[kbenson]

Note: This is all in the context of Perl 5. You can assume the following works with little or no changes in Perl 6, along with probably 3+ other new ways to do it (which is actually one of my peeves about Perl 6).

There's a few things. Full word but lower precedence boolean operators (and, or, not) which allows for combining statements in a way that &&, || and ! doesn't always facilitate, but really shine in making boolean statements more readable. e.g.

    die "some problem" unless defined $some_var and not $some_var eq "foo";

But I think you somewhat missed my point. What you've done in your example, is easy to read, but you've either unconsciously or consciously switched the order of some statements so they are valid in the context of Python. This is trivial and easy with simple conditionals, but if they are complex it can hide the point of the statement, which is that this is a shortcut to the next loop iteration. I find putting the "verb" first can make for much easier understanding of what's going on when it gets more complex. A comparison of that might be something like the following:

    for my $item ( @items ) {
        # Standard barrage of tests
        next if test1($item) or test2($item) or test3($item)
            or test4($item) or test5($item);
        # If it's a special item, do a couple more tests
        next if test_guard($item) and ( subtest1($item) or subtest2($item) );
        # If it's an end marker, skip the rest
        last if is_last_processable($item);

        ...
    }

Even though the actions are condensed, I quickly know what the point of each one is, and what it does. Condensing them also allows me to comment each without feeling I'm cluttering the logic and making it more verbose than needed (too verbose, and you raise the likelihood related code will be off-screen or not as easily visually associated, which hampers comprehension), but event without the comments having the defining action start the line helps clarify intent. I imagine in Python, the continue statement would either be far to the right from larger conditionals, or moved to a more traditional scope underneath taking up an extra line, or split into multiple if statements. This is also a good example in Perl of where the community has come to a fairly good consensus that while you can make very complex postconditional statements, don't, as it defeats the purpose (just split it into multiple simple ones or use a traditional precontitional if formatted to be more readable, or some other technique such as computing portions of the condition separately and comparing them later).

Also, regarding if pre or post positioning, I feel that Perl allows the statements to be expressed as you might say them or think of them. That's the point of postconditionals in Perl. Also, like how you would express them verbally to someone, a postconditional only works on a single statement (it does not support blocks through braces). You wouldn't normally say "do X, do Y, do Z if A is true" and expect it to apply unambiguously to tasks X, Y and Z. On the flip side, a preconditional not only supports braces, it reqiures them, since the simple one statement case is easily handled through the postconditional. e.g.

    # Valid
    if ( $A ) {
        do_something();
    }
    if ( $A ) { do_something(); }
    do_something() if $A;
    
    # Invalid
    if ( $A ) do_something();
    { do_something(); } if $A;

This is an example of one of the places Perl not only allows you to use natural expressions to express yourself, but guides you away from odd or problematic ways of doing so (i.e. ambiguous speech patterns).

As for sigils, some people really dislike them, but I find the useful. I see them a little signifiers of the nouns in any statement (and the type of noun, of which there are only a few).

Finally, there's "context", which has a specific meaning in Perl, and is probably the most interesting and unique thing about the language. It can be very useful, but the complexities can sometimes cause interesting behavior that was unintended or non-obvious initially. That said, its also what makes a lot of the "magic" (really just the rules put into action) of the array and hash data types work, so it's not something that could feasibly be removed (and nor would I want it to be). Instead, knowledge of the problematic spots is acknowledged by the community, so we try to avoid those problems, and for the most part they are old problems (this is usually a function that may produce multiple values being using within the definition of a hash or array in list context, exemplified by decades old projects based on CGI.pm which has been deprecated).

[vram22]

Wow, the fact that Larry Wall was a linguist and (along with many others, I'm sure) applied those skills (about the nuances of human languages) to the design of Perl, really shines through in this comment. Thanks.

[ricardobeat]

Lots of other languages have postfix conditionals.

On the readable boolean ops, all the Perl people recommend shying away from them except for a few specific constructs (do or die, eval or do, etc), since the weaker precedence rules make it really easy to shoot yourself on the foot:

    $a = $b or $c;

Where $a will never be assigned the value of $c.

[kbenson]

> Lots of other languages have postfix conditionals.

I didn't make a case as Perl being the only language, just that it's an interesting aspect of Perl. That said, I would be interested in what languages you are referring to. I haven't seen many.

> On the readable boolean ops, all the Perl people recommend shying away from them except for a few specific constructs (do or die, eval or do, etc), since the weaker precedence rules make it really easy to shoot yourself on the foot:

They are perfectly acceptable in a boolean statement. You only need to shy away from them when mixing them with assignments or higher precedence boolean constructs. The only case where you would have to worry is in non-simple boolean statements with assignment in the statement, or functions that omit parens for arguments in some cases, or mathematical operations without grouping parens, all of which I would argue should include their own grouping parenthesis for clarity anyway.

That said, I devoted space in both of my comments in this thread to noting that there are definitely places where you might shoot yourself in the foot with some of these features, and you'll note the examples I used them in are exactly as you've described, where they are either after a postconditional (in which case it's kept to a simple boolean statement which has no ambiguity), or to affect control flow (e.g. return or die), in which that assignment doesn't matter anyway.

> Where $a will never be assigned the value of $c.

Which I never used as an example for that reason, but that's the point of those operators. Being lower precedence allows for some alternate constructs than is possible in many other languages without them.

Someone asked for examples of constructs that help Perl match mental models of how might think of an algorithm, so I decided to explain a few. The purpose isn't to point out how Perl is better than Python or some other language, but how it's different in an interesting way. A lot of that was planned, but sometimes that came out to its benefit, and sometimes to its detriment. Like most interesting new things (because at the time it was), it's not entirely one thing or the other.

[vram22]

>I didn't make a case as Perl being the only language, just that it's an interesting aspect of Perl. That said, I would be interested in what languages you are referring to. I haven't seen many.

I'm not the one you replied to, but Python has got, not postfix conditionals, but what I might call infix ones, for lack of a better name. Here is a nested example:

Using nested conditional expressions to classify characters:

https://jugad2.blogspot.com/2017/04/using-nested-conditional...

[chombier]

That's a really nice explanation, thanks.