Why?
Mainly for marketing reasons. As I don't see a technical benefit - and I can see a number of technical advantages with the current solution. As I see it there are two or three ways that detractors criticise perl. The first is that Perl is an interpreted language and therefore "slow", the second (aluded to in Rot13 Source Jumbling) is that your code can be "stolen" because the source is always visible. Thirdly (and in some ways its a part of #2) there is no easy way to bundle up the modules you need into one lump for easy distribution.
Technically it is reasonable to argue that these are in fact strengths (and I seem to recall some recent posts by merlyn doing just that) and I am not proposing that it be required that perl only have a 2 stage process. However I believe it could be advantageous to have the option of a perl "compiler" and Perl "runtime engine" available as an alternative for those who wish to ship code in a bytecode format.
In some ways this seems like a logical extension of the PAR module and/or perlcc program. What I am proposing is that the intermediate format, something like 'perlcc -B', become supported as a method of code distribution / execution.
Ok so what are the benefits?
Well, the big one is that it allows you to produce perl code that is run on regular user's machines - a program like popfile, which has been discussed on this site in Perl for the Masses, is potentially useful to millions of people but is messy when distributed in source form. For a commercial product, which you do not wish to release under an open source license, the messiness is even worse as the source code of your program including comments and everything is visible to all your customers unless you deliberatley run it through an obfuscator. If you are want to do that why not get some speed advantage also by shipping in bytecode format?
Another advantage is that it eliminates version mismatches. Now I have to admit that perl programs do not seem to suffer too much from version issues, but even the gods are not infallible and it is definitely useful - for mass distribution to non technical users at least - to be able to remove weird version glitches as a possible reason why the program doesn't work on a customer's machine.
Finally there are situations where you want run a perl script many times but need to be sure that the script starts from a consistent spot. The problem with the mod_perl approach is that you can get unexpected results because some data turns out to be persistent. Of course this sort of thing is a bug, but it is easier to make the scalability argument if you say that you can take the source code, precompile it and your service now goes N times faster.
Thoughts?
Dingus
In reply to Should we have PerlC and PRE? by dingus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |