But actually look at the SOURCE of Moo instead of a toy example, and I see plenty of stuff that's exactly the kind of suboptimal readability I associate with perl....sigils all over the place, @_, the lack of proper function argument handling, etc.

Any toy example can be made to look clean.

Yeah, sorry man, at the point where you complain about sigils you've disqualified yourself from the discussion for lack of thinking things through far enough. Thanks for playing, bub.

Why, "bub", most sane languages don't have such cryptic, hard to read incantations. But you're obviously a zealot with a closed mind so I'm not sure why I'm even bothering to reply.

Using words like "sane" and "cryptic" and "incantations" doesn't really seem to fit an argument in good faith, but assuming you're sincere, I can explain.

Perl uses sigils for two reasons. First, to provide a separate namespace for variables and language keywords. Second, to allow amount contexts.

Reasonable people will disagree about the value of both of those reasons, but those are the reasons why sigils exist in Perl.

Apparently one of the mods decided i shouldn't be able to reply, thus different account. Here's a serious answer for you:

You complained about the simple presence of sigils, without even stopping to think and consider what advantages they bring. I may be rude, but close-minded? No.

Explain how requiring a sigil in the default case improves readability.

Imagine how ugly C would be if every variable that wasn't a pointer dereference had to be prefixed with $.

I am not necessarily opposed to meaningful sigils, e.g. Ruvy's @, but using them everywhere is a pure misfeature that hurts readability.

I'll happily explain, thanks for asking.

First off, in Perl the parens for a function call are not mandatory.

As such it is very useful for functions and variables to be visually difference, especially when you're using functions to generate parameters for other functions without any temp variables inbetween.

my W = qq_mult ConjugateQ, qv_mult RotationQ, Vector;

You can't tell at a glance what's going on and will need to look carefully. Adding sigils makes it quite clear:

my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

Further, most languages have only one type of variable, a name for a single thing. Perl has multiple types of variables that behave differently. For example:

my $res = munge $one;

I see this and know that the function munge is passed one single variable. However, consider this:

my $res = munge @two;

If there wasn't the @ there, it would be easy to assume that munge gets exactly one argument. However the @ there alerts us to the fact that @two is an auto-flattening array, and munge will end up with anywhere between 0 and MAX_INT arguments passed to it.

Similarly with hashes:

my $res = munge @two;

They also auto-flatten, so they need to be marked as being different from scalars, but they also flatten in a very different way from array, in that they flatten into a list that alternates the keys and values. So they need to be marked differently from arrays.

Lastly, due to functions, variables, array and hashes having explicit sigils, they can be recognized by editors without any heavy analysis, enabling editors to mark these four types with different colors, which is extremely useful. Personally i don't see the sigils anymore, and instead just see the colors with which the types are highlighted.

(Bonus set: Actually C is often written with sigils too. I've often seen code where variables are prefixes with p_, s_, a_, i_, etc. They are not enforced by the language, but people often force themselves to use them. The downside: They are inconsistent from project to project and have to be relearned every time.)

> You can't tell at a glance what's going on and will need to > look carefully. Adding sigils makes it quite clear: > my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

Actually, that's clear as mud. Is this a function call of 3 arguments? Function composition/chaining, an array of 3 items?

You're right. I did not explain that well enough. Even with sigils it is unclear whether qv_mult will take 1 or 2 arguments, or whether qq_mult will take 1, 2 or 3. What is however clear is that only qq_mult and qv_mult are function calls, which it previously was not. Worse, what i did not mention then: When reading carefully it was easy to tell that they had to be function calls; however it was impossible to tell whether the two quaternions and the vector were variables, or function calls that did not take any arguments. Only with sigils becomes this clear.

I'm still unclear on what the dataflow is... is w set to the value of the qq_mult call and the rest just executed for side effects?

Regardless, please defend how that is not just an improvement over, but better than, say:

    my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

    w = qq_mult(qv_mult(CondugateQ, Vector))
         

or whatever the precedence and dataflow semantics are

That example doesn't show it very well. To be clear: The intended advantage is: Parens are optional. That permits syntax like the following to be implemented in pure Perl without changing the parser:

    try {
        die "foo";
    }
    catch {
        warn "caught error: $_";
    };

If parens were mandatory, it would need look like this:

    try(
        sub {
            die "foo";
        }
        catch(
            sub {
                warn "caught error: $_";
            }
        )
    );

Having the nicer form in the first example is possible only because sigils are mandatory, along with auto-flattening variables and easy code highlighting.

As for the example, with mandatory parens it would look like this:

    w = qq_mult( ConjugateQ, qv_mult( RotationQ, Vector ) );

In production i'd write it like this:

    my $W = qq_mult $ConjugateQ, qv_mult( $RotationQ, $Vector );

That gives a nice balance between a low number of parens, and clarity of intent.