I think if I took that attitude when I started at my current
job I wouldn't have wound up being asked to train most of
the other programmers how to use Perl.
I wholeheartedly agree that any good Perl programmer should
know the precedence rules. That does not mean that their
code should be written using them all if you have any
expectation that it will someday have to be altered by
someone not as conversant as you.
But this is a disagreement we won't settle any time soon.
One of my sillier mistakes was to have this argument with
Tom C. You know that I deliberately limit myself to a set
of constructs that I think I can teach to others. The one
I was responding to is simply not common enough for me
to want it on a short-list of things I have to teach. OTOH
another time I showed a construct I had to deal with (that
was written by someone else) to
p5p and got general
shock and horror about how convoluted it was. Plus one
of my favorite quotes ever on programming from Tom C:
A programmer who hasn't been exposed to all four of the imperative,
functional, objective, and logical programming styles has one or
more conceptual blindspots. It's like knowing how to boil but not
fry. Programming is not a skill one develops in five easy lessons.
I think that when there are valid and valuable constructs
that can cause that much reaction on a list with as
many tuits as p5p, it is beyond
the bounds of reason to expect most companies to have people
who could maintain a code-base that uses all of them.
For bystanders, the construct handed to me is this:
print join ",", map { &{$field_info{$_}{format}}($deal) } @fields;
I pointed out that I had cleaned it up. Thanks to merlyn
it got cleaned up a bit more, and this construct shows up
from time to time in my code like this:
my @field_subs = map {$field_info{$_}{format}} @fields;
# TIME PASSES
print join ",", map {$_->($deal)} @field_subs;
In fact a variation of it appeared in my first post here,
at A few style suggestions. |