Yeah, I've often wondered how much faster Perl 5 would be if it didn't have to support a whole bunch of deprecated and/or obsolete features from previous versions of Perl. (Granted, the support for the feature discussed in this post probably has a minuscule impact on perl's performance, but there may be others that are not so negligible.) 1%? 10%?
| [reply] |
Speed was not my concern, and I certainly wouldn't
quibble over a 10% speed issue. (The user generally
won't even notice a speed difference until it's at
least 50%.)
The reason I am looking forward to dumping all the
legacy Perl4 malarke is because of its impact on
coding, especially in terms of unexpected behavior
and bugginess.
Consider, for instance, an issue we recently
ran into with SVG::Metadata, as follows: this
module had been using XML::Twig to parse the metadata
from SVG files. (SVG is an XML format.) Bryce had
set it up to use Twig's simplify method to produce
a hash-reference structure, which the code in
Metadata.pm's parse routine was navigating in more
or less the usual way, e.g.,
$metadata->{'rdf'}->{'Work'}
and so forth.
However, as we started dealing with SVG produced
by different SVG editors, we found that we were
running into namespace issues; some SVG might
list those elements as RDF:rdf and cc:Work, for
example. So we put in code, similar to the
above, but with extra logic like
$elt->{'rdf'} || $elt->{'rdf:RDF'} ||$elt->{'RDF'}
to check for those. Oops. Do you see
the problem? Neither did we, at first.
What on earth is a pseudohash? Turns out, it's
some kind of inane legacy thing from the days of
yore before Perl supported references, and as a
result, you aren't allowed to test for a hash
key containing a colon, if it might not exist.
Serious bugs result. We ended up dumping the
simplify()'ed hash-reference structure entirely
in favor of XML::Twig objects and their methods,
like
$elt->first_descendant('rdf:RDF')
Granted, I'm more comfortable with the methods
anyway, now that I have taken the trouble to
download about half of XML::Twig's rather lengthy
POD into my brain, and it does allow us to dispense
with checking for optional intermediate wrapper
elements, and the resulting code is probably less
buggy too; nevertheless, I spent hours ironing
out this issue. I seriously doubt I'm the only
one ever to bang into it. Who would have thought
that a hash key (which is, after all, just a string)
would have issues with containing a colon? Boo, hiss.
There are other legacy Perl4 things besides the two
we've discussed in this thread. They're all going
away in Perl6, and I'm glad.
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."
— Pratico & Van Pelt, BBHG, p68
| [reply] [d/l] [select] |