Recently, a question was asked on the Perl Beginners mailing list about how to sort data with embedded dates. All of the data was stuffed into a scalar with two newlines separating each row (though I suspected that the person asking the question may have gotten that incorrect). Basically, we were presented with the following scalar:

my $data = "buy 1/23/01 100 12.625 50 25.25 \n
 buy 09/1/01 100 12.625 50 25.25 \n
 buy 10/23/01 100 12.625 50 25.25 \n
 buy 10/25/01 100 12.625 50 25.25 \n";
[download]

I split the data and sorted it with a Schwartzian transform:

my @data = split /\n\n/, $data;

@data = 
    map  { join ' ', ( $_->[0], ( join '/', @{$_->[1]} ), $_->[2] ) }
    sort { $a->[1][2] <=> $b->[1][2] || $a->[1][0] <=> $b->[1][0] || $
+a->[1][1] <=> $b->[1][1] }
    map  { [ $_->[0], [split /\//, $_->[1]], $_->[2] ] }
    map  { [split( /\s+/, trim( $_ ), 3) ] }
    @data;

sub trim {
    my $data = shift;
    $data =~ s/^\s+//;
    $data =~ s/\s+$//;
    return $data;
}
[download]

When I sent the snippet, I also included an explanation of how the transform works. However, I'm wondering if this is an appropriate way to go. I need to teach new tricks to some of the old dogs that I work with and I can't help but wonder if an approach like this is likely to generate more confusion than enlightenment.

If any of you monks have experience teaching Perl to others, how would you approach something like that? map is a beautiful bastion of functional programming in the procedural world of Perl, but I suspect that taking the time to outline a procedural approach would have been better. It certainly would have been easier to understand. Would you strive to present a simplistic, but easy to understand solution, or one that more accurately reflects Perl's capabilities? I've been having a heck of a time getting across some of Perl's strengths to one of my coworkers and I need to start considering some different tactics. Should I dumb down Perl?

Oh, and feel free to clean up the code above, if you think my solution is overkill.

Update: Hmm... I guess this also goes back to my worries about maintainable code. What happens if I do something complicated that others are not likely to understand, but seems like the best solution. Should I code for clarity? We've been interviewing some Perl programmers who are totally clueless ("strict just gets in the way", "local and my are the same thing", etc.) and if this is the norm, "baby Perl" may be appropriate. I'm beginning to despair of finding anyone worth hiring (who we can afford, that is :)

Come to think of it, I might be one of those 'clueless' programmers. I definitely have some production code I don't want anyone to see :( And yes, I'm dead serious about my possibly being one of those 'clueless' programmers (this is enough for another meditation). I know how to program Perl, but my knowledge of putting complex systems together is spotty at best. I could use a mentor in that regard, but no one else I work with is qualified.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.