> To me this perl5 vs 6 example you cite reads like someone came up with the syntax specifically to do those tasks.
I routinely see both example and $dayjob code that reads as if the syntax and builtins were made just to make that bit of code nicer to write and read. But I've watched the relevant discussions so I can see this is the natural outcome of a good language design process rather than Larry Wall focusing on parlor tricks.
> So there's a method that just happens to pick any number of array items?
Yes. It picks randomly and does not repeat an element. Handy for selecting threads from a pool, for example.
> A lot of us would call those features bloat.
Imo it is suitably huffmanized and pushed as far out of the technical core as is reasonable. I see it as excellent design.
> Cross operator such as "X~" which appears to mean something like 'combine two lists in every possible way with 2 implied for loop, then stringify every item, then return the list' sure is powerful, but I'm a boring stick-in-the-mud and do not really see that as much of an improvement over the two for loops.
More or less. If an infix X is followed by another operator it applies the operator pairwise for every operand combination and returns the list of results.
But you can still write two for loops if that's what you prefer...
> More to the point, assuming we really do want to get rid of explicit for loops, then why not compose the functionality out of functions from some Perl module?
That's more or less how it already works. String concatenation (~) and many other operators (+, -, etc.) ship with the stock Perl 6 but you (or others) can add more (which will then automatically combine with the range of metaops).
> Think of: cross(@a, @b) yielding some Pair objects of the two lists, rather than @a X @b. And rather than some weird operator like X~, perhaps there should be a stringify(cross(@a, @b)). I guess it's just not the Perl way, though, but I know which language I'd rather write.
Folk can write code long hand if they want. You can write add(3, 4) instead of 3 + 4 if you want.
But key things get lost in the translation you suggest. The metaops like X parallelize. And what if @a and/or @b are lazy or infinite lists? And what about an optimization specific to crosswise string concatenation?
> Ditto for expressions like (1, 2, 3) >>+<< (3, 2, 1) yielding (4, 4, 4). This seems like rank madness to me. Python's NumPy would do the same with something like array((1,2,3)) + array((3,2,1)) yielding array(4, 4, 4). Why not use the existing library facilities and overloading capability to build this stuff?
How do you parameterize the operation of the + op? For example, how would you control the +'s handling of unequally shaped arrays? Hang on, let me go check this. ... Ah. With NumPy, "the size of the trailing axes for both arrays in an operation must either be the same size or one of them must be one" or an exception is raised. The Perl 6 syntax allows more refined control of what NumPy calls broadcasting.