Old debate, it's a core philosophy or the language. It's a bit like complaining that there are a 100 ways to cook chicken.
Personally, I like the freedom that Perl offers. Perl 5.x is still widely used in some industries, finance and banking for instance, and it's still the glue that holds 'nix systems together (have a look at the scripts in the bin folders of any distro).
Following Modern Perl[1] best practices, you can write powerful, meaningful and expressive Perl 5 without shooting yourself in the foot.
Perl 6 is another beast, it removes many of the ambiguities present in Perl 5 and introduces more functional paradigms.
At its core, Perl remains a multipurpose tool. The fact that there are multiple ways to do a thing is not bad, whether it suits you or not is a matter of personal preference really.
So, if someone is curious about Perl, they should be encouraged to try it and find out for themselves if they like it or not.
That's a wrong way of looking at things. The right way is to see how a language adapts per your thinking for writing complex functions. When you look at things from such an angle, its highly restrictive if a language expects you to always bend towards its one true ideology.
A nice language will offer you enough creative ammunition and will do as you wish while you are busy at more important things.
The unary sort is useful for two reasons. It simplifies the code AND it does key caching.
But sometimes you need BOTH a key extraction closure (to get key caching for performance) AND a comparison closure (to specify a custom sort). In P6 you just specify both closures (P6 figures out which is which because one has one arg and the other has two).
Here's the P6 equivalent of your last couple lines:
["A","b","C"].sort: { .lc } # A, b, C
["A","b","C"].sort: *.lc # same thing
Here's a custom sort:
["A","b","C"].sort: { $^b.lc leg $^a.lc } # C, b, A
Now combining them:
["A","b","C"].sort: *.lc, { $^b leg $^a } # C, b, A
colomon is right. Thanks for pointing this out colomon.
Sorry HNers and P6ers.
I feel so embarrassed. I'm usually almost pathologically careful. I have an explanation if anyone wants it but I suspect an excuse is uninteresting so will skip that for now.
Instead I'll say I am now committed to trying to implement this (it's in the spec, just not yet implemented) by updating Rakudo's sort method:
The good news is that it's (currently) about 10 lines of code. The bad news is they look very gutsy to me. Oh well. Open mouth, take responsibility, do your best and all that.
Great stuff, nevertheless the following is a surely a regression:
> Note that in Perl 6, cmp is smart enough to compare strings with string semantics and numbers with number semantics, so producing numbers in the transformation code generally does what you want.
Perl 5 had a clear distinction between "cmp" (string comparison) and "<=>" (numeric comparison). Trying to work out the data type, and thus the comparison approach, from the actual data itself, is surely going to create subtle bugs, that don't appear in testing, but do appear with live data.
I should have also said that a great deal of thought went into making the default behaviors for "cmp" robust. But if (as in the article's example) you're producing numbers in the transformation code, "cmp" is guaranteed to do the right thing for you. Likewise if you produce strings in the transformation.
"Likewise if you produce strings in the transformation" What if you produce strings that look like numbers? Where, for example, extra leading zeros differ in significance between string and numeric comparison? Surely trying to use heuristics for this stuff is always a recipe for disaster, as with the == operator in PHP?
Perl 6 has proper types. If you produce a string, you are producing a Str object (well, technically it could be an object that does the Stringy role, but I don't think there are any other Stringy types implemented yet) and it will compare as a string, not a number, no matter what it looks like.
Likewise, if you produce a number, you have an object which does the Numeric role, and it will compare as a number.
This caught my eye as well. As a Python programmer who never learned Perl, this validates some stereotypes. Or maybe it's the budding Haskell programmer in me. "smart enough"? Sounds pretty dangerous to me.
I don't know what stereotypes you are referring to, but Perl is actually one of the better loosely typed languages for not causing the aforementioned bugs. And also one of the best languages for not overloading operators too (which is one of the reasons it looks like executable line noise)
So don't use the comparison operator that attempts to detects the correct type and use the operator made for the specific type you know you are comparing?
If an operator has no use (i.e. you should always use a type-specific operator) then why is it in the language at all? If it's there, someone will use it, and if it shouldn't be used, then that's bad that someone uses it.
Why would you use a type specific operator in a quick script where you don't need to really think about typing and all your perl 6 variables are typed as 'Any' as they aren't specifically typed?
I think ve was saying, ve doesn't see the difference between python's `sort(key=...)` and perl6's `sort { one-arg block }`. (At any rate, I don't see that difference.)
I realize this is drifting off topic, and I could well believe the current Rakudo implementation doesn't actually save the memory (I could believe it does, I just don't know) but P6, for any method, including sort:
my $a = [2,1]; say $a.sort; say $a # 1 2 2 1
my $a = [2,1]; say $a.=sort; say $a # 1 2 1 2
This riffs off the general op= syntax:
my $a = 1; say $a + 1; say $a # 2 1
my $a = 1; say $a += 1; say $a # 2 2
One thing this article does not cover is that, even if a comparison function doesn't do anything slow, there is still the fact that it still has to do a Perl function call O(n log n) times. At least in the equivalent with Python, I think it is advised to use the key function rather than comparison funtion for this reason, for speed. Though I guess a key function needs to take more space if it is to memoize.
A one arg closure to the P6 sort builtin (eg { .lc }) is a key function, not a comparison function. Imo the P6 sort builtin is an elegant rethink of P5's Schwartzian Transform, which was invented in 1994 to address precisely the point you make.
I agree, this wasn't a point about Python vs Perl.
All I'm saying is that the author bills it as not wanting to run { .lc } twice per comparison. What I'm adding is that the comparison function itself, even if trivial, arguably has a bit of an overhead just from calling it. Thus, having O(n) calls to a key function { .lc } may be better than O(n log n) calls to a comparison function {.lc <=> .lc}.
At least that's how people convinced me to use key= instead of cmp= in Python.
While it appears that Perl 6 has many impressive features, I'm much more interested in practical matters such as: module versioning, installation, & removal; the state of MoarVM; and the state of the tutorial book.
After years of the spec being nice but the implementations being very basic, the module versioning and installation implementation in Rakudo is finally shaping up. I anticipate it getting pretty robust over the next 6 months. Imo FROGGS' day 11 advent article is poorly written but might be useful:
http://perl6advent.wordpress.com/2013/12/11/day-11-installin...