(Shrug...) What can I say, Will? It may astound you that I would say ... “I don’t particularly care that “my code will run ‘way faster!’ ”

Really, the only thing that matters to me is that the software ... that is to say, the software that I have, and, that is to say, already ... produces the correct results, and that I can prove it.

Furthermore, the actual extent of compiler-induced measurable improvements to the runtime of any code whatsoever is, at this point in time, a remarkably slight delta. It is the stuff of “Whetstones” by now. To make significant improvements to any compute algorithm, you have to change the algorithm. Therefore, the usual actual business response is to “throw silicon at it (again),” thereby avoiding both the uncertainty and the expense of changing source, instead trusting Moore’s Law to once again save your business bacon. After all, a capital investment in a $30,000 souped-up piece of silicon is nothing compared to the unfathomable expense of touching “paid-for source code that works.”

The essence of your “commandments” is that “source-code change” is not only ‘free,’ it is ‘a Good Thing.™’ ” Most unfortunately, this is not the case. Aye, there’s the rub ...

“Source-code change” ... is not an option.

Think about it ... “why t’hell was Moose so successful, when it is a Wart on top of a Hack on top of a Bunion to try to make Perl-5 the object-oriented language that it never was, and never was intended to be?” The short answer was that you could use Moose; to put on your Super Suit, and-d-d-d... that you could utter no Moose; to take it off again. All of which enabled you to make Useful Improvements To™ “the garbage what you were stuck with” without “starting over.” Sure, it was “inefficient,” but then again, “Chips Are Cheap.™” And so, so it goes.

And this is very much what has made some of the truly-innovative “hacks,” like Moose, be so successful and widely-accepted. It was “a significant improvement” that you could take advantage of with relatively low business risk. It’s not simply that you can use Moose;. It’s every bit as much, if not much-more, that you can also say: no Moose;. You can mix the old with the new.

“why t’hell was Moose so successful, when it is a Wart on top of a Hack on top of a Bunion to try to make Perl-5 the object-oriented language that it never was, and never was intended to be?” The short answer was that you could use Moose; to put on your Super Suit, and-d-d-d... that you could utter no Moose; to take it off again. All of which enabled you to make Useful Improvements To™ “the garbage what you were stuck with” without “starting over.”

I've already answered this question to you and others in this thread, so I'm just going to start copy-and-pasting until y'all start actually reading my responses. Here you go!

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!

2. We can add back in all the high-magic components after we've got RPerl v1.0 working with the low-magic components.

Now, on to your point about the supreme importance of software returning the correct results. I totally agree. That's why we have test suites. So, we make sure RPerl passes all low-magic test cases and thus "prove" (to borrow your term) that RPerl will run your low-magic code correctly.

I never said that source code change is free. It is, in fact, due to the large cost of source code change that I am writing a new compiler to automate it for me as much as possible. I don't ever want to have to change my source code because it is not fast enough, I'll have RPerl take care of the speed for me.

You say that compiler-induced improvements are small, this is patently incorrect. Early benchmarks show RPerl's Perl data mode runs 7 times faster than pure Perl, and RPerl's C/C++ data mode runs 199 times faster than pure Perl. You say the only way to gain significant improvements is to change the algorithm, which is also patently incorrect. You need only STOP USING SO MUCH DANG MAGIC. Please do your homework!

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other