On Tue, 2005-04-26 at 10:48, Luke Palmer wrote:
> Aaron Sherman writes:

> > The reasons I don't "use English" in P5:
> > 
> >       * Variable access is slower

> Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster.  (Actually
> they're the same: on each run a different one won, but just barely like
> this).

Remember that I'm a Perl 3 programmer who has just gotten used to this
"5" thing... ;-)

I sometimes lose track of the ugly hacks that have been rationalized
into workable practice over the versions. "use English" used to require
an extra level of indirection in the implementation, but clearly no
longer does. I don't have a perl older than 5.6.1 to test against, but
this was probably back in the 5.002 or 5.003 timeframe. I'm guessing.

> When will you people stop caring about speed that doesn't matter.

This matters. I'm not going to switch around all over the place, I'm
either going to use the English names everywhere or the punctuation
names everywhere, not a mix of both -- THAT would be terribly unreadable
-- and back when that access hurt (I did measure it), I could not have
afforded to use the English variables in tight loops. For example:

        while(<>) {
                if ($. == 1) {
                        print "Header: $_";
                $total += $_;
                if (eof) {
                        $. = 0;

This was the very sort of thing that convinced me not to "use English"
back in the day, when I measured performance of one reporting program
with and without English variables. I found that with them it took about
10 minutes longer than without. Without won.

> Ever since I stopped caring about speed, I've started to write code
> almost twice as fast.  And the code itself isn't slower.  

Ok, so let's separate the premature optimization from removing massive
bottlenecks from code. When I can get a reporting program that takes
30-60 minutes to run to drop 10 minutes in execution time, I'm going to
do that. This is NOT premature optimization.

What you describe is what Knuth has also described. You should never
worry about trivial details of optimization while writing the minutia of
a program because a) you don't know if that bit of code will even exist
in the final version b) the optimization might be better accomplished at
a higher level c) you might be PREVENTING optimization opportunities at
a higher level!

> And I promise, that will never be somewhere where the difference between
> $/ and $INPUT_RECORD_SEPARATOR matters.

It used to be. Clearly the ugly hack that was "use English" has been
fixed. Old lessons are not easily unlearned.

Either way this is not really about Perl 6, is it?

Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Reply via email to