Re^2: top ten things every Perl hacker should know

[Your Mother]

Brute Force programming is not always a bad idea. Elegant code is often slower and harder to maintain.

I agree with the first premise. The supporting reasons are less good. A complicated Schwartzian transform may well be impossible for a first-year Perl hacker to read but it's 100 times easier to read than the 2 screenfuls of code it replaces if you know what it is. Elegant, to me, means better, concise, more lucid, not too tricky to follow.

[jcoxen]

There's a difference between elegance for elegance sake (ie. doing something tricky because it has a high geek factor) and elegance because it's good programming (e.g. the Schwartzian transform). I was thinking more of high geek factor code. It might parse better if I s/often/sometimes/.

Jack

[apotheon]

"Tricky" or "clever" is not always elegant. I tend to think of elegance as eschewing the gratuitous. That would mean writing clever code for the sake of being clever does not fit my definition of "elegance".

[tilly]

Bad example.

A Schwartzian transform in Perl is always more complex than a straightforward sort block. It is good to know about it because it can be lots faster, but it is more complex.

If you do not understand this, then you don't really understand the Schwartzian transform.

(Note that I have to say "in Perl" because other languages, for instance Python and Ruby, have implemented shortcuts to make Schwartzian transforms simpler than the alternative.)

[Your Mother]

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.

[tilly]

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;

Here is the same code written as a normal sort.

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

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]};

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.)

[johngg]

The problem with the "straightforward sort block" is that you often have to surround it with lots of other code to achieve the same results as the ST. At the heart of it, the sort complexity is the same and the difference lies in where you mangle the data into a sortable form and then extract it again. If I understand correctly, it is the Guttman-Rosler Transform that has a simpler lexical sort after the sort keys have benn carefully packed into a string.

Cheers,

JohnGG

[tilly]

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.