It's all right in front of you; in one sweep of your eye. The filtering, the modification, and the sorting (grep, map, sort, and maybe more). There aren't a couple sets of temporary variables and three or more bocks or subroutines to jump around and try to keep in your head at once. It's the same code condensed. I find it easier to read and much easier to debug.

So I do think the ST is a good example of elegance. I'm open to counter examples of what you consider Perl (not Python or Ruby of course!) elegance.

Let's take a list of files and use a Schwartzian Transform to sort it by file size descending, then alphabetical order ascending.

my @sorted_files
  = map {$_->[0]}
    sort {$b->[1] <=> $a->[1] or $a->[0] cmp $b->[0]}
    map {[$_, -s]} @files;
[download]

Here is the same code written as a normal sort.

my @sorted_files = sort {-s $b <=> -s $a or $a cmp $b} @files;
[download]

Clearly the Schwartzian Transform is more complex. But if you have a list of 1000 files, it's also about 10 times faster. Which is why we learn it.

Now to explain my Ruby comment. In Ruby, arrays have a sort_by method. So in this example you'd write:

sorted_files = files.sort_by {|f| [- test(?s, f), f]};
[download]

and you've written the more efficient sort with less code than the regular sort. This does not work in Perl first of all because we don't have a sort_by method, and furthermore because Perl doesn't do anything useful when you try to sort array references. (Ruby sorts them lexicographically, with each field sorting in its "natural" way.)

We sort of have a sort_by method in Sort::Maker. But I've never liked the api. There is no denying that an ST is a scary sight to a new programmer not familiar with the idiom. I'd argue it should be wrapped in a sub for clarity most often.

I like the PBP argument for using List::Util and List::MoreUtils functions such as any rather than idiomatic uses of grep. It makes your intention clear, and prevents you from thinking in syntax - no matter how comfortable and familiar that syntax is.

update: added some words for clarity

Cheers,

JohnGG

Try to come up with an example. With real code. You'll find that the straightforward sort really is more straightforward.

You'll find time after time again that the straightforward sort block is simpler to write in Perl than the fancy sorts. OK, thinking carefully about it, there is one exception. And that exception is where the code to extract "what you want to sort by" is very complex, so that it is more complex to do it both for $a and $b than it is to do it once and have a Schwartzian Transform. But I don't think I've ever encountered that in real life. (Plus one can just move the complex logic into a function and call the function twice. With anonymous functions one can do it inline, and it will still be simpler than a Schwartzian Transform.)

And, of course, someone who hasn't studied sorting tricks is always going to find the straightforward sort block far easier to read.

However the sort block executes more times than mangle/extract blocks do in the Schwartzian Transform or the Guttman-Rosler Transform. So the more work you move from the sort blocks to mangle/extract, the more time you'll save. The GRT is faster than the Schwartzian Transform because it uses a simpler data structure (a string), and so the sort block can be made even faster (in fact it is the default string compare).

People think that this is cool because they are surprised that this change can have such big performance implications. But it is an optimization, and the code you get is more complex (at least in Perl).

Update: hv noted that I'd written GST instead of GRT. Fixed.

I'll take one of my ST sorts and translate it to "straightforward sort block" style and see what happens. I'll give you an update when it's done.

Cheers,

JohnGG