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.
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:
as you did, or you can still use the same style Perl 5 uses: Oh, and that anonymous subroutine syntax? The old way still works for that as well: But let's not forget that we can omit parens: And also that we can omit sub entirely because the braces will be interpreted as a block because of the signature: 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.