|Perl: the Markov chain saw|
I do not know if this project is really going to go somewhere, but I definitely find some interest in it if I understand it correctly. I do not understand why it triggers such heated reactions, but possibly I am lacking some of the historical background.
First, let me state clearly that I love what you call the "magics" of Perl and I am not willing to sacrifice that on the altar of speed, because this is the essence of Perl in my view, and that's one of the main reasons I love Perl. Speed is also very important to me, because I am dealing daily with pretty large amounts of data (dozens of GB), but, to me, making easy things easy and difficult things possible (whatever the exact phrase is...) is just more important. Most of the time, Perl is fast enough anyway for me (although, yes, I have sometimes to change my algorithm to get it to be fast enough). And there are a number of things in your "Low-Magic Perl Commandments" that I am not willing to accept. I want to be able to use tied data, code refs, closures, prototypes, etc.
Having said that, when I have a severe performance problem, I would be quite happy to use a limited Perl subset if that solved my problem. From what you said, Will, if I understand correctly, it seems that it would be possible to have all the "magics" when needed, and apply the Commandments when speed really matters. Did I understand this right? If this is correct, then I think this is worth the trouble, the best of two words, I think you said somewhere. Given the "law" that 10% of the code usually accounts for 90% of the duration time, I would probably be willing to write those 10% in "low magics" Perl if that gave me a real performance increase when I need it, provided I can still use the high magics in the rest of my code. If this means that I can write this low magics 10% in limited Perl (rather than Inline C, XS or whatever), and can have the Perl that I love for the rest, then I think that I might be willing to buy your idea. Is my understanding correct or did I extrapolate too much on your comments?
One last (but not least) point of concern. Your site states somewhere that RPerl is free for non commercial use. What does that mean exactly? Does that mean that companies would have to pay for using RPerl? If such is the case, then, sorry, I won't be with you, this is against my principles, I want these things to be free, in both senses of the word (free beer and free speech, as R. Stallman would say it, which does not mean that I agree with him on everything, far from that), and I am ready to donate money to make this possible (and i have done it quite a few times), but I certainly don't want to pay a license for using a programming language.
Well, to conclude, the idea of your project looks promising in my view, and I would really be inclined to encourage you to go further, but I would need to know more to be able to make an educated opinion. Your site is often somewhat vague (your benchmark, for example, seems promising but some sentences ring some alarm bells in my mind, like the words "hand compiled", or something like that, used somewhere. What does that really mean? Is this an actual test of a product or even a prototype, or is this a "Proof of Concept" slide-ware for the sucker?
Well, sorry if I am a bit harsh, I really don't mean to be nasty and I am really interested in your concept, but I would like to know more.
In reply to Re: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments