Yes! It side-steps domain knowledge. Lets expand on this point.

Consider this code:

  if ($a->is_xxx_yyy && $b < PPP_QQQ) { ... }
[download]

An experienced Perl coder would instantly, subconciously, grok the control-flow within it. Part of this understanding relies on convention, so could be subverted, but just look at the amount of information/expectation we have:

• $a is an object (the -> operator)
• is_xxx_yyy is a predicate (starts with word "is")
• is_xxx_yyy has no side effects (because its a predicate)
• If is_xxx_yyy is false, then $b is irrelevant (&& short-circuits)
• PPP_QQQ is a constant (upper-case)
• PPP_QQQ is numeric (the numeric comparison)
• $b is numeric (ditto)
• The rhs has a single boundary (the inequality).

So we'd know that there are 3 paths through the control logic of the if statement, and be able to see how they interact. Bad coders could subvert my expectations (e.g. they could add side-effects to the predicate): but "hard cases make bad law".

Compare this with an abstracted function call:

  if (xxx_yyy_ppp_qqq($a,$b))
[download]

The perl-brain gleams no information from this. Understanding it relies entirely on the quality of the name of the identifier. And we all know how hard it is to create a really good identifier name.

--Dave