|P is for Practical|
I do applaud you for the non-anonymous remarks, even if I strongly disagree. :-)
...to reap what "benefits", exactly?
I thought by now the answer was obvious to everyone. YOUR CODE WILL RUN WAY FASTER.
Is this a cost that I can justify?
Sure, if you want YOUR CODE TO RUN WAY FASTER. No brainer.
It was “a significant improvement” that you could take advantage of with relatively low business risk. You can mix the old with the new.
Now you're just messing with me, right? I've explicitly and clearly stated this 3 times in this thread alone! Come on, man, get with it. To YET AGAIN quote myself:
Also, we can use the "no magic;" pragma to turn off magic for 1 subroutine at a time, which means we can mix low-magic RPerl code (fast) with high-magic Perl code (maybe less fast), giving us the best of both worlds!
As I've stated already, you can mix compiled low-magic code with normal non-compiled high-magic code.
1. We can mix low-magic code with high-magic code.
2. We can add back in all the high-magic components after we've got RPerl v1.0 working with the low-magic components.
Simply and politely put, your arguments ARE TOTALLY INVALID.
In reply to Re^2: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments