I think this will go a long way to making Perl "take over the world", and produce more shrink-wrap software.
Right now, Perl applications are limited because ordinary consumer-type users can't simply "install", and utility programs are sometimes criticized that users don't have Perl on that target system.
For commercial software, users should not know or care what language it was written in. On the Windows platform, for example, a user will insert the CD or download an installer and the rest is automatic. A non-installing utility program will be a single *.exe file that runs anywhere and need only be accessible.
It doesn't matter if it's written in C++ or Delphi, as it gets the same resulting format in the end. Now Java is a little different, since the "system" (of whichever brand) needs to be installed too, but they tried to make it look pretty much the usual.
Visual BASIC is a more successful example. The compiled .exe file needs the run-time .dll that contains a bunch of stuff. The ActiveState perl.dll is half the size of that VB dll.
So, what Perl 6 needs is an inate and elegant way to do basically what Perl App does: bundle all the modules together and produce a single distributible file. Only instead of extracting the files at run-time, it should either "link" the compiled form within the file, and access "files" via an archive structure within the single file (e.g. like the Java JAR files).
Meanwhile, compiled binary code will speed up the starting of large major apps, though this startup time has become insignificant on small utilities.
So, I want to write up a position paper on why this should be a goal in Perl 6, and specifically what is it that is good. But first I'm musing over it to clarify my own position, and I'm looking for what others have thought about it.
In reply to Pre-position musing on "standalone executables" by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |