I find that nesting logical assertions helps the reader understand what a string of maps and greps and sorts is doing. Yes, in theory, the programmer is supposed to use intermediate variables, but no other language has the same piping that Perl has, so Code Complete never addressed the issue. I've seen merlyn and theDamian both use a similar form to do the Orcish manauver or Schwartzian transforms. *shrugs*

As for mandatory args ... *sighs* This is similar to another problem I have that I posted somewhere, but don't have the motivation to find.

*ponders* Wouldn't something like the following work?

sub printUsage {
    my ($mandatory, $optional) = @_;

    print "Usage: $0\n";
    print "-$_ ", uc $_, " " for @$mandatory;
    print $/;
    print "[-$_ ", uc $_, "]" for @$optional;
    print $/;
}
[download]

Of course, the formatting isn't as good. I'll leave that as an exercise for the reader. *grins*

Update: I changed how I did the calls into Getopt::Long. Please critique.

my @mandatory = qw(user to_db to_sid to_site);
my @optional  = qw(password vendor type model);
my @default   = qw(from_db from_sid);

our $from_db  = "some_db";
our $from_sid = "some_sid";

my $args = {};
my $rc;
{
    no strict 'refs';
    $rc = GetOptions($args,
                     (map { "${_}=s" } @mandatory),
                     (map { "${_}:s" } @optional),
                     (map { ("${_}=s", \${"$_"}) } @default),
                    );
}

printUsage(\@mandatory, \@optional, \@default)
    unless $rc;
printUsage(\@mandatory, \@optional, \@default)
    if grep !exists $args->{$_}, @mandatory;
[download]

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Actually Code Complete does address this exact issue. I don't have it in front of you so I can't give page numbers, but they talk about the importance of not reducing lines of code by putting more on one line. I think it was talked about with particular reference to C's trinary operator.

As for the question of whether nesting logic helps or hurts, my experience is very strongly that it hurts my comprehension. What I find best for handling nested maps, greps, and sorts is to put them on separate lines, indented, to be read from bottom to top. That is the same strategy with any complex control logic. If it is a single "thought" in your program, make it into line-noise. If it is central to how your program works, break it visually along the lines of how it is to be understood.

I have seen similar styles from other programmers. Including both merlyn and TheDamian. Again, I sometimes break out logic, sometimes don't. But if it is central to what I am doing, I break it out. Likewise if I start getting multiple control statements on the same line and want to reach for && as a control statement, I break it out.

As for the question of whether other languages have the piping that Perl does, I disagree. Here is a Schwartzian sort of a pipe-delimited list on the 3'rd then 5'th columns (ascending then descending) in Perl:

my @sorted = map {join, "|", @$_}
  sort {$a->[2] cmp $b->[2] or $a->[4] cmp $b->[4]}
  map {[split /\|/, $_, -1]} @my_list;
[download]

Here is how you do the same thing in Ruby:

sorted = my_list.map {
    |i| [ i.split(/\|/)[2,4],  i ]
  }.sort.map { |i| i[-1] }
[download]

Do you see? Chaining method calls achieves exactly the same effect as Perl's pipelining does, and it even has the benefit of reading more naturally left to right! So the formatting issue is hardly unique to Perl...

What I find best for handling nested maps, greps, and sorts is to put them on separate lines, indented, to be read from bottom to top.

I do this as well, my only issue with it is where to put the listor array, on the same line as the last transformation or the line below? Also I can never quite decide how to deal with 'blockless' transforms such as sort.

@list=map  {substr($_,1)}
      sort
      map  {pack("CA*",length($_),$_)}
      @words;
#or
@list=map  {substr($_,1)} sort
      map  {pack("CA*",length($_),$_)} @words;
[download]

About your example from Ruby, are you allowed arbitray whitespace in between the transforms? ie could you write that as the following?

sorted = my_list.map {|i| [ i.split(/\|/)[2,4],i ]}.
                 sort.
                 map { |i| i[-1] }
[download]

...even has the benefit of reading more naturally left to right!

Well, while it wouldnt be difficult to write a class that supported this type of syntax, I have to say that i'm not so sure that this is more natural or not. In fact, while I dont think it would be that hard to get used to or even that it would bother me, I would actually argue that it is less natural than the perl notation, which I hasten to add does seem a little odd at first, seemingly going against the convention in a program that lines are executed in order from top to bottom. This I believe is because it is easy to think in terms of statement execution rather than what is really happening, list assignment, or function chaining.

For the sake of clarity in my argument Id like to point out that normally values move from the right to left in statements. $x=$y; for instance involves evaluating the right side and placing its value in the container on the left side. With lists we extend the idea to that of 'pouring' values from the right side into the left side.

Now when I see  @greets=map{"Hello $_!"}@names; the idea is extended so each value from the list at the right goes left, into the block and then left again into the array. And so on when we have longer chains. This also matches the way it would be written if these were all functions.

@list=map(substr($_,1),sort(map(pack("CA*",length($_),$_),@words)));
[download]

Whereas the method form would translate into a multistatement equivelent

my @tmp = map { pack("CA*",length($_),$_) } @words;
my @tmp2= sort @tmp;
my @list= map { substr($_,1)} @tmp2;
[download]

Which makes sense when written as multiple statements, but when written as one statement as you showed in ruby it actually seems to be unnatural. The result gets taken from the extreme right hand side and stuck in the container on the left side, which hardly seems more natural than the values flowing consistantly from right to left.

Just my $0.02 :-)

Yves / DeMerphq
--
Have you registered your Name Space?