Re: I think Perl ruined me as a programmer

[bart]

I think you're not even listing the most time-saving features of Perl. The examples you give are just peanuts, in my opinion. You're not even beginning to touch Perl's real strong points. For example, how many lines does it take to write a universal min function? Not many:

sub min {
    my $min = shift;
    foreach (@_) {
        $_ = $min if $_ < $min;
    }
    return $min;
}

There aren't many other languages that produce such a powerful function (the minimum of any number of items, the minimum value in an array, or a mix, like the minimum value in 3 scalars and 2 arrays) in so few lines.

And that's where my laziness lies.

Another example? Data::Dumper. Enough said.

[Limbic~Region]

bart,
Or simply List::Util 'min';

There was a signature going around a while back along the lines of "90% of all perl programs are already written". On top of that, Perl let's you code in your paradigm of choice (imperative, OO, functional). Taking your min() example a few steps further, you end up with reduce. I have found it incredibly difficult to spend much time learning other languages now that I have found perl.

[tilly]

Ironically I consider that one of Perl's weak points compared to other languages.

Take your min function. Suppose I want to use it to find the first word in a list. Can I? No! I have to write another function for strings! And if I want to compare arrays in lexicographic order, I need another one! (That one gets nasty, particularly with arrays of arrays.)

Compare Ruby (or Python, or Haskell, or Smalltalk). There the exact equivalent min function would work on any data type that defined <. So it would work on integers, floating point, strings, arrays of things that are themselves comparable, and so on. But Perl can't do that! Why not? Because Perl has typed operators and untyped data. Those other languages have typed data and untyped operators. So in those languages it makes sense to "compare these things" with the most natural possible comparison. In Perl it doesn't.

Sure, Perl is much better than Java in this regard. But that is a deficiency which generics can help with. By contrast Perl's deficiency is not readily removable, it is inherent in Perl's notion of data that automatically casts itself to whatever it is asked to be. (A notion which does, of course, pay off in other conveniences.)

[TimToady]

This is fixed in Perl 6, not with generics, but with multiple dispatch. The prejudice of == toward numerics and eq toward strings is then merely the behavior of the default function that is invoked if a more specific type does not define a more specific behavior. (Of course, generics can help with defining a set of related functions for a new type.) And, of course, you also handle mixed types with multiple dispatch, since that's what it was invented for in the first place.

[tilly]

That helps with your own data types. But since most programs just use the default data types, it still takes more work in Perl to define a generic min function that works across strings and numbers.

And, to tell the truth, in Perl 5 you can already use overload to define a comparison function and then use a fairly generic min function. Of course people don't actually use this much in practice. For many good reasons. Most people haven't learned what they can do with overload. Also it is a fair amount of work (Perl 5 doesn't have multiple dispatch to help). And using overload like this in shared Perl code violates the principle of not surprising your maintenance programmer. And finally because for most programs it is more convenient to use default data types.

That said, the first bug I found in Ruby was that if you defined a subclass of String that is exactly like a String but it compares in reverse, the built-in sort method from Comparable will ignore your comparison and use the normal string comparison. I was told that this bug is due to a deliberate optimization. I just tested it. The bug is still there. :-(

So even having a clean design doesn't help you if you break your own design for performance reasons.

[mreece]

that min functions looks kinda funny, and in some ways manages to expose the dangers of writing lazy (ie, terse) perl.

sub min {
    my $min = shift;
    foreach (@_) {
        $_ = $min if $_ < $min;
    }
    return $min;
}

@a = (10, 5, 8, 2, 1, -4);
$min = min(@a);
print "min of @a is $min\n";

produces: min of 10 10 10 10 10 10 is 10

probably not what you expected! not only did it give the wrong answer, it destroyed the input list!

[Anonymous Monk]

The function should be:

sub min {
    my $min = shift;
    foreach (@_) {
        $min = $_ if $_ < $min;
    }
    return $min;
}

[Anonymous Monk]

or, to avoid warnings about the occasional undefs in your arg list:

sub min {
    my $min;
    for (@_) {
        next unless defined;
        $min = $_ if $_ < $min
    }
    $min
}