On Fri, Nov 01, 2002 at 01:42:45PM -0500, Perrin Harkins wrote:
> >It sounds like you're saying that you should only use a subset of Perl
> >as some programmers may not understand the other parts of it?
> That is what I'm saying. I'm aware that this is a controversial opinion
> in the Perl world. However, I think it's reasonable to know your
> audience and write for them. That's the good part of More Than One Way.
> The New York Times writes their articles for a certain reading level,
> and I do the same with my code.
In principle, I broadly agree with this ... but ...
> Note that different audiences have different levels. You can expect
> someone who opens up the code in a module on CPAN to be pretty fearless
> about advanced Perl ideas. On the other hand, the people in my current
> office are mostly novices so I try to take it easy on them when writing
> code for work. I will still use a Schwartzian Transform if I need one,
> but I'll put in a comment saying "this is a Schwartzian Transform, see
> such and such URL for an explanation." Same deal with things like
> hash-slices, and I try to avoid using $_ when it isn't necessary.
... but I think that there should be a certain level of ability that
should be assumed when coding commercially ...
I'm all for abstracting away the really deep magic and serious perl
wizardry into modules that less experienced programmers shouldn't need
to delve into in the normal course of things, but things like map,
hash slices, and even $_ aren't what I could class as advanced Perl ideas.
I would expect anyone being paid to work with Perl to understand these -
they're going to be popping up all over the place in code, and aren't
that easy (or sensible) to hide away.
And the best way for novices to learn these concepts is to see them
properly used throughout the code base, not for their use to be shied
away from.
> So would I, in that situation. It's not that map is so evil, but rather
> that I have often seen people overuse it (especially after a
> first-reading of "Effective Perl"), and write confusing code with it by
> jamming too much into the "map { some stuff } @list" form.
Agreed.
But 'proper' use of map can be explained fairly simply. It's not a
difficult concept.
Tony
