I'm glad you picked argument passing as your example, since the ugliest piece of bad Perl I've ever seen(Hey, two out of three ain't bad) is argument passing.

I was beginning to maintain an out-of-house piece of Perl, and was happily reading through it sorting the small pile of wheat from the large pile of chaff when suddenly I hit a brick.

The programmer had, I think, intended to get the kind of default arguments that hashes can easily provide.. but had tried to do it without any kind of hash. They also had odd argument ordering, with related arguments randomly places around the sequence so often the value you needed to default would be in the middle of the 'full' list. I think they were just adding new items to the end as they became required.

I'm now in a new job, so I can't get this code to show you, but here's the essence of how it worked. I'm refusing to comment this, for those Initiates of Perl who can't work out how this works think yourselves lucky and go and reread the hash method.

And yes, the 'use strict' and -w bits were added by me for my example. They didn't use these either, oddly enough.

#!/usr/bin/perl -w

use strict;

DoStuff (1,2,3);
DoStuff (1,3);
DoStuff (2);

sub DoStuff {
  my ($a, $b, $c) = (-1, -2, -3);
  if ($#_ == 2) {
    ($a, $b, $c) = @_;
  } elsif ($#_ == 1) {
    ($a, $c) = @_;
  } elsif ($#_ == 0) {
    ($b) = @_;
  };

  print "A= $a\n";
  print "B= $b\n";
  print "C= $c\n";
}
[download]

I'm thankful not to be in that job anymore.

Other bits of wonder I've seen..

• Regexps used for XML parsing which also rely on the positions of newlines. Good thing the same company wrote the program which generates the XML really.
• A nice bug where someone was initialising hashes with '%hash = {}' instead of '%hash = ()' and then wondering why they were getting a nonsense result.
• A recursive program that executed itself with backticks.
• Form-driven CGIs which took parameters like "delete * from users where username='eric'", where the eric bit was template-driven as the form was output. The programmer couldn't see why this was a security hole as he knew what he'd printed.

I love maintaining the code of people who don't really know Perl, it's ingenious some of the things they can get up to.

...but this is proof not of the ugliness of Perl, but of the ugliness of someone's mind.

Where that person wrote:

sub DoStuff {
  my ($a, $b, $c) = (-1, -2, -3);
  if ($#_ == 2) {
    ($a, $b, $c) = @_;
  } elsif ($#_ == 1) {
    ($a, $c) = @_;
  } elsif ($#_ == 0) {
    ($b) = @_;
  };

  print "A= $a\n";
  print "B= $b\n";
  print "C= $c\n";
}
[download]

We might instead write:

sub DoStuff {
  my ($a, $b, $c) = @_;
  $a = defined $a ? $a : -1;
  $b = defined $b ? $b : -2;
  $c = defined $c ? $c : -3;

  print "A= $a\n";
  print "B= $b\n";
  print "C= $c\n";
}
[download]

And while this lacks some elegance (for instance, I might want to create a loop that simply tests $_[0] and then shifts the top value into the next of my variables), I think it would be a simple improvement.

The real point is that the language allows us to be ugly. Some of choose to do so.

---v

Note that if there are 2 arguments, the original code set $a and $c, not $a and $b.

-Mike

I believe this allows Perl to be regarded as a tool for expressing one's creativity

That it is. While this flexibility is very nice most of the time, it does unfortunately also lead to things like Perl Poetry. (Hi to all the poetry fans out there =P)

Perl's main drawback is that parts of it are irredeemably ugly, complicated, and must be used with caution

You don't blame the brush if you can't paint do you? Yes, encounters with some poorly written code do occasionally turn people off Perl. However, to look at one piece of code, say that's ugly, and write off a language is rather naive. People who are serious about finding the best tool for their job will look a little closer and realize the benefits of such flexibility and how to use it to their advantage.

Update: Also part of the quote you linked to...

Because some limiting design decisions early in Perl's history could not be reversed, many of the more advanced features have a fragile, jerry-rigged feel about them.

That I will agree with.

That's why I try not to pass too many arguments -- it's a sign that the function is too complicated.

This is why you always have a param checking sub that you turn off unless $ENV{DEBUG} or something is true. There's plenty of examples of this type if thing on CPAN.

Do these check that all uses of the param hash use the right keys? What you describe sounds to me like a sub that's called when populating the hash from @_ -- that's a good idea, but it's still not strict enough. I've come across code that uses 'style' in one place and 'stytle' in others.

Clamped, read-only, psuedo-, or tied-hashes can fix this, but they're probably rare in production code.

I wouldn't mind this convenience occasionally...

Compare the following (which are directly from your writeup):

### Parameters explicitly listed
sub createIndex {
    my ($dbh, $indexName, $frontend, $backend, $scoring) = @_;

    ...
}

### Parameters passed in by hash, but no documentation
sub createIndex {
    my %args = @_;

    ...
}
[download]

If I'm new to a project, or if I'm coming back to a project after a few months working on something else, the second version becomes more difficult to use/modify/understand - the method becomes less of a "black box", in my opinion.

I'm going to be somewhat of a heretic here, and say that function definition in other languages, such as C, C++, and Java, looks better and is easier to understand. For example,

public void createIndex(Connection conn, String indexName, String fron
+tend, String backend, int scoring) {
...
}
[download]

For me, the only issue with this is flexibility. If you don't want one of the parameters (say, scoring), you have to overload createIndex with a second instance of the method. Done wrong, this could lead to code duplication. Done right, there is one "base" method that can handle all cases, meaning no code is duplicated. It's just not as flexible as the Perl version.

A lot of my time recently has been spent considering how another programmer sees my code (another programmer was recently hired where previously I was the only one). We had to come up with certain rules for Perl programming, rules that we sort of took for granted in Java. This suggests, as you say, that Perl allows you to be more creative - but you have to weigh your creativity against your need to get the job done. I'm not saying that you can't have both - I program because I am creative. I've found that on the job, you have to be careful about how you program.

Update: Fixed a typo.

--PotPieMan

I believe this allows Perl to be regarded as a tool for expressing one's creativity and culture while still doing his/her job. This is unarguably a good thing.

Imagine that a year or two in the future, you are the sole maintenance programmer for a system developed by ten programmers all given full rein to their individual expressions of creativity and culture. All the more reason for enforcing a site standard in style and structure.

Of course, in a well managed team, peer reviews and code walkthroughs should remove the most extreme cases of wierd individual style.

I have seen so many variations of this statement and it still seems to say absolutely nothing to me about Perl. It seems to me that you could put almost any language at the front and find some aspect(s) of it that fit the description.

As regards the arguement-passing convention, is it really so complicated? that much more so than say C's? And there is such an elegant way to use the parameter passing, the hash method; In most languages such a divergent solution from the standard wouldn't be possible.

I started using an example of a string in C but decided it was long winded and didn't really add anything... It just made me happy I have Perl.

Here's my horrible confession. We often hear that you can program Perl to resemble your favorite programming language/style. C-style for loops are the classic example:

for ( my $i = 0; $i < @array; $i++ ) {
 ...
}
[download]

We're admonished to avoid that, if possible, due to classic "off by one" errors.

my @array = qw/ zero one two three four /;
for ( my $i = 0; $i < $#array; $i++ ) {
    print $array[$i],$/;
}
[download]

LISP programmers appreciating the aesthetics of the Schwartzian Transform is another example.

Confession time: I used to be a COBOL programmer. Oh, I used strict, warnings, taint checking, and whatever else I thought was "good", but I had a bad habit of writing my subroutines "COBOL-style", with the exception of passing in the arguments.

sub foo {
    my $arg = shift;
    foreach my $data ( @data ) {
        $bar[ $data ] += $arg;
    }
}
[download]

I know better now, but it took me a long time to see the error of my ways :(

Cheers,
Ovid

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