Actually I think you have that backwards, as far as front-loading.
For just about everything you do in Perl 5 there is an equivalent in Perl 6 that is simpler to remember and is more general in its use.
For example using an iterator variable other than `$_` in a for loop:
Perl 5:
for my $line (...) {...}
Perl 6:
for (...) -> $line {...}
Note that you can also use this for any keyword that has the form `KEYWORD CONDITION {BLOCK}`
if $a.method() -> $result {...}
You can also use this exact same syntax for a lambda:
@a.sort( -> $a, $b {...} )
So you can see it is more general, and since you can and do use it everywhere it is easier to remember.
The other day I was trying to remember how to alias two subroutines in Perl 5;
*foo = \&bar;
I can easily remember how to do it in Perl 6
my &foo = &bar;
The things shown in this article would be very much black magic Perl 5 code, but are completely doable. If you can manage to keep from writing source filters, I think you can avoid doing the things shown in the article.
The mutability is also the reason you can import modules from other languages as if they were written in Perl 6. You just have to make sure you have the appropriate Inline module installed and loaded.
My point is that while some of this is intuitive and carries throughout the language, I think they went too far by not just adding a new way of doing things that's consistent, they kept the old way(s) as well, and usually added a second new way to do something.
In an effort to keep the language similar looking to those used to Perl 5, there's both functions and methods for almost all core operations. You can call:
@a.sort( -> $a, $b {...} )
as you did, or you can still use the same style Perl 5 uses:
sort( -> $a, $b {...}, @a);
Oh, and that anonymous subroutine syntax? The old way still works for that as well:
sort( sub { ... }, @a);
But let's not forget that we can omit parens:
sort sub { ... }, @a;
And also that we can omit sub entirely because the braces will be interpreted as a block because of the signature:
sort { ... }, @a;
Just today I was explaining to a coworker what multiple dispatch was and how it could produce some novel solutions. For example, I remember (but annoyingly could not find) someone had implemented a solution to a Microsoft scripting challenge to score a bowling game give the score for each frame (including "/" and "X"), and someone had coded up a succinct and interesting solution using multiple dispatch.
It looks interesting, and when presented together, it seems concise and easy to understand, but the truth is that nothing keeps the functions definitions all that local, so it allows for your execution branching and logic to be spread into disparate files, and a later addition of a function or method to change the control flow of the program. Given that these signatures also take into account subtyping, where it's often not possible to figure out where a call will resolve to prior to runtime, and not even good tooling is going to help you. Add in possible coercion, and it's even more complicated.
I love Perl, and I love having options, but as with everything in live, there's a happy medium, and places where you can go too far and not far enough. I think Perl 6 went too far with choices, and what's more it completely lost the thread with steering people towards the better way of doing things, which was also a big part of Perl 5 in my experience.
I really started seeing this when Larry starting playing with using sigilless variables. I suspect Larry was using them because he could and to have fun, but I really couldn't see the positive of them. In a language where you expect variables to have sigils and other identifiers to be functions (or constants, usually defined as simple functions), it really pointed to a problem in the design process to me. Just because something can be included, doesn't mean it should be, and blindly stuffing everything into the language and assuming that you can make them play together just as well as a slightly smaller set of features that's more curated smacks of a bit too much hubris.
To return to my point of too many options and features, if Perl 6 had actually been willing to do away with the syntax of Perl 5 and just go with the method syntax, I think that would have gone a long way towards keeping the things a reader had to keep in mind while reading it down. I understand why they didn't, because I've been following it from the beginning, but that doesn't mean what we're left with is a good situation. It parallels the name situation in a lot of ways. The biggest problems Perl 5 and Perl 6 ever had were each other, which is a shame. Both languages are wonderful in their own way, and would have been better off much more loosely associated. Unfortunately, that boat sailed a decade or more ago.
Sorry if I went a little overboard, but this has been percolating for a while now.
For just about everything you do in Perl 5 there is an equivalent in Perl 6 that is simpler to remember and is more general in its use.
For example using an iterator variable other than `$_` in a for loop:
Perl 5:
Perl 6: Note that you can also use this for any keyword that has the form `KEYWORD CONDITION {BLOCK}` You can also use this exact same syntax for a lambda: So you can see it is more general, and since you can and do use it everywhere it is easier to remember.The other day I was trying to remember how to alias two subroutines in Perl 5;
I can easily remember how to do it in Perl 6 The things shown in this article would be very much black magic Perl 5 code, but are completely doable. If you can manage to keep from writing source filters, I think you can avoid doing the things shown in the article.I will note that this mutability makes it so that for example OO::Monitors http://modules.perl6.org/dist/OO::Monitors:github:Jonathan%2... can be made easily.
The mutability is also the reason you can import modules from other languages as if they were written in Perl 6. You just have to make sure you have the appropriate Inline module installed and loaded.