This subject was discussed recently at Pre-position musing on "standalone executables".

As I said there, I too think that the ability to package perl scripts in a bytecode form would be extremley useful for a variety of reasons.

• Ease of deployment.
• Reduction in startup time.
• A certain amount of protection for the author of commercial work.

I think with Perl 6 and the parrot engine, many of the reasons that make this non-viable for Perl 5 tend to disipate.

Once you can drop into Parrot to achieve things not possible (or too slow) in native perl, the need to use XS, I think, will likely go away. Of course there will still be modules that consist of interface wrappers around C-libraries and they would still need to be deployed (in binary form) along with bytecode applications and the perl runtime, but that is standard practice for many other languages; on the windows platform at least.

If the parrot engine turns out to be as efficient as the promise suggests, maybe many of the current modules that use C-libraries could be re-built using a C to parrot translator?

Whilst notionally, it may seem wasteful to package modules 'statically linked' with each application. In reality, the size of the bytecode will in almost every case be far less than the same modules source code. So concerns regarding squanders resources don't really hold up. This is especially true when you consider that each application would only need to carry with it the bytecode for the modules that it actually uses. For a very high percentage of applications, this means that not having to have all the core modules source code on the target machine (or available via a share), the static linking would result in a reduction of resource usage rather than an increase. Especially as the application could itself then be much more easily deployed across a network using a NFS-type solution than perl itself.

Whilst it is true that any non-perl/parrot components of modules would still need to be compiled on each target system type, which in the *nix world of multiple variations means that CPAN would still need to serve sources rather than bytecode. In most corporate environments there are a limited number of platforms (usually 1 or 2 at most for sanities sake:), However, the number of each type can be in the thousands. Being able to bytecode compile and package internal applications targeted at those (internally) standard platforms would be a huge benefit.

Whilst it can be argued that a similar effect can be achieved now by deploying Perl and the source of the application on a centralised server. In many corporate environments this is not the case. Take the example of the large retail chains. They have the need to deploy their internal applications not to several thousand workstation across one huge hetrogenous networked environment, but rather to a few dozen workstations at each of several hundred sites. In this environment, the need to set up a perl installation at each of those hundreds of sites means that perl does not get a look-in.

The ability to build and deploy stand-alone applications would go a long way to easing perls entry into this kind of application. I can say from experience that in one very large project, perl was muted as an option (which I personal voted against at the time for entirely different reasons*), but was eventually squashed as an option purely on the basis of cost of installing and maintaining perl installations at 2000 sites!

* I should add that were I now to be making the same decision, it would be different. Having seen the problems that arose from the alternative that was chosen, and with the benefit of my new found knowledge of perl, I truely wish that perl had been chosen for that project. I firmly believe that it would have saved an enormous amount of time, cost, trouble and resource.