Sorry to disappoint you, but I am dealing with several projects, consisting of several million lines of source-code in aggregate, which are in revenue-earning production right now. The clients in question are not the slightest bit interested in rewriting them from scratch to deal with your “Commandments,” which would be a multi-million dollar capital expense with no return on investment. (They prefer for the systems in question to continue to earn millions, and/or to continue to reliably support business processes that right-now do so. Perl-5, in this case quite literally, “moves the freight.”)

Please don’t continue to bother to trumpet the supposed virtues of an improvement that no one in the business world can ever afford/choose to make. Computer software technology does not exist in a vacuum; does not sit on a high mountain and chant, waiting for enlightened pilgrims to come to it.

Please find a way to provide, instead, even a 5% improvement (let’s start small and work up ...) on some key aspect of what Perl-5 does right now ... to be done in such a way that no source-code changes are mandated, and that the full backward-compatibility of all key modules (DBI, Template, JSON, to name a few) can be objectively proved in-advance.

You find yourself “a voice in the wilderness” because the business-risk of what you propose is incalculable while the return-on-investment is essentially zero. Yet, you continue to talk very loudly. Why not focus instead on some perhaps very-small but well-chose aspect of what the customer actually wants, and find a pragmatic way to do even that small thing? This is what will put your name in lights.

RPerl will retain full backward compatibility with existing Perl 5 and XS code, which means that RPerl can compile the low-magic parts of your code while leaving alone the high-magic parts. This will provide the small speedup for average Perl 5 code which you request, with no source changes necessary and full backward compatibility. If you are married to high-magic code, then you can have the best of both worlds. The low-magic components can be made to run up to hundreds of TIMES faster via the RPerl compiler.

And I most certainly shall continue to trumpet the virtues of fast code. Anybody who wants their Perl 5 code to run fast will take heed. I need my Perl 5 code to run fast, so the customer is built in! If you don't care about your code running slow, then perhaps RPerl just isn't for you.

Keeping in mind your continued demonstrations of your lack of comprehension of basic computing concepts, databases, threads (honestly, I could go on and on all week), I weep not only for your customers (should they actually exist and this not be more marketing doublespeak of yours), but for the poor schlubs who who read your “advice” without reading associated responses disproving your quackery.