[Israel.pm] What's new in Perl 5.10

Jason Elbaum jason.elbaum at gmail.com
Tue Dec 25 05:14:34 PST 2007


> Smart Matching in Perl 5.10
> http://www.szabgab.com/blog/2007/12/1198487688.html

I actually think this new feature is representative of one of Perl's
design flaws.

Larry Wall sees Perl as based on a number of design principles, most
of which I agree are good guidelines for programming language design.
But some of them tend to conflict with each other:

1. "Different things should look different. Similar things should look similar."
-> http://www.perl.org.il/presentations/larry-wall-present-continuous-future-perfect/transcript.html

2. "Do What I Mean" or "Do the Right Thing."

The problem is that doing "the right thing" requires the compiler to
do *different* things with the same (or very similar) code, depending
on its understanding of the "right" thing.

In this case, we have a single operator ~~ which can either mean:

- Do these numbers have the same value?
- Do these strings have the same characters?
- Do this number and this string represent more or less the same thing?
- Does this string match this regular expression?
- Is this element found in this array?
- Is this element one of the keys of this hash?
- Do these arrays have the same elements?
- Do these hashes have the same keys?
- etc., etc., etc.

Keeping track of all these cases and how they interact is not
necessarily intuitive, and will likely call for frequent reference to
the documentation. That's because they're fundamentally doing
*different* things, even though they all look the same.

And when you say it checks if two arrays have the "same" elements,
does it check whether they are identical? Or whether they succeed when
smart-matched themselves?

Finally, note that with eq for strings, == for numbers and ~~ for
smart matching, Perl still lacks any single operator which can tell
you if two scalars (let alone two arrays or hashes) are simply
identical - contain the same exact string and/or number and/or undef
and/or reference. (That may be an impossible mission because of
automagical string/number conversion in scalars - another example of
DWIM conflicting with different things looking different.)

Unfortunately, the "I" in "DWIM" refers not to the programmer but to
the compiler. I'd rather the compiler always do something
well-defined, obvious and consistent, rather than applying complex
heuristics which ultimately make "simple" code do hard-to-guess
things.

The more I use Perl, the more I conclude that DWIM is a language
design anti-pattern. It's a shame, since on most of his design
principles, Larry is right on the mark.

Regards,

Jason Elbaum



More information about the Perl mailing list