This safer version of the chop entry elsewhere in
this document removes any trailing string that
corresponds to the current value of `$/' (also
known as $INPUT_RECORD_SEPARATOR in the `English'
module). It returns the total number of
characters removed from all its arguments.

Suppose you're prompting user to say something:

print "Do you prefer foo or bar? [foo]";
if (chomp($_=<STDIN>),$_ and $_ eq "bar") {
    print "A fine, if a bit non-traditional, choice.\n";
} else {
    print "Do you know the origin of word 'foo'? So do we.\n";
}
[download]

That's how I would implement it, if the behaviour would have to be just that; if user types exactly "bar", then that, otherwise "foo". Would you do the same?

Assuming you would, here's my gripe; why does chomp act like that, modifying the argument instead of returning the changed value? Right away I can't think of any function (well, chop ...) besides chomp which prefers to change an argument instead of using a return value. It seems clumsy, too; as you can see from above example, you need a named temporary variable and a separate command to clean it. So much cleaner would sound, chomp(<FILE>) eq "bar", to me, at least.

And for what benefit is it like that? Return value, number of characters chopped ... is essentially a boolean, since return value is either 0 or length($/) (unless, of course, we're going to get RE $/ some day...). Well, that information is useful in its way too, I suppose, but every context I've so far used chomp in would have needed the mutilated value rather than the information whether it was chomped. I use chomp only to make sure variables are clean, I don't care whether they were dirty before. Do you?

Did I miss something essential here, or is this just some relic from days long past?

P.S. That this is in Seekers instead of Meditations should point you out that that last sentence is not rhetorical.