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.
A nice language will offer you enough creative ammunition and will do as you wish while you are busy at more important things.
["A","b","C"].sort {|a, b| a.downcase <=> b.downcase }
["A","b","C"].sort_by {|k| k.downcase }
["A","b","C"].sort_by &:downcaseBut 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
["A","b","C"].sort: { $^b.lc leg $^a.lc } # C, b, A
["A","b","C"].sort: *.lc, { $^b leg $^a } # C, b, A
> 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.
list.sort(key=lambda x: x.lower()) key=str.lower
key=operator.methodcaller("lower")
python can sort according to a function (using the "key" parameter) or using a custom comparator function (using the "cmp" parameter)
as a side note, Python offers also a sorted[0] function, applyable to any sequence
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.
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...
Rakudo/MoarVM began running this month. As Larry Wall said a few days ago "failed 179 test files ... which ain't too shabby at this point" http://irclog.perlgeek.de/moarvm/2013-12-21#i_8029074
Afaik the Perl 6 book is not really being updated. Maybe this info is of interest to you: http://www.perlmonks.org/?node_id=1033899