in reply to Re^3: Perl in the Enterprise
in thread Perl in the Enterprise

That doesn't cut it. I'm aware of the executable archive bundles that are possible -- but something that creates such redundancy by bunding another Perl compiler with every single executable just doesn't really cut it, particularly since it really cuts against the grain for developers who spend so much time trying to eliminate redundant code. Whereas the ease of distribution of an independent executable application serves the social need of end users, the lack of a need to distribute a parser with every single installation of a given application serves the social need of the developers -- and lacking that, developers tend to focus on users who already have the parser, or use a different language.

Sure, it can be handy to be able to create these executable archives sometimes, but use of that capability tends to be the exception rather than the rule.

Also . . . I'm not talking about bytecode (which needs a VM to run), but a stand-alone persistent binary compiled executable file.

print substr("Just another Perl hacker", 0, -2);
 - apotheon
CopyWrite Chad Perrin

Replies are listed 'Best First'.
Re^5: Perl in the Enterprise
by tsee (Curate) on May 21, 2006 at 09:17 UTC

    Sorry, I disagree. PAR-built binaries can be built to use an external perl5X.dll or .so. Furthermore, you needn't bundle all modules you use into the binary. You can conveniently pack a set of modules into another .par file*, then ship the perl58.XXX, the library.par and any number of binary executables which use the modules in library.par and the shared library.

    Now, if you say that we've just moved from a one-file distribution to a three-file distribution, well you're right, but it doesn't matter. There are virtually no substantial applications in the world that do not need a library or another. And packing three files into a .msi or .nsi installer for Windows users is not exactly daunting.

    * This works as follows. Given a lib.par file containing a bunch of, say, Gtk2 modules, you can do "perl -MPAR=lib.par -e 'use Gtk2;...'". You can also "use PAR qw/lib.par/;" from your code to load the specified PAR archive and add its contents to the @INC search path. (Or actually a CODE hook, but nevermind.)

[reply]

      PAR-built binaries can be built to use an external perl5X.dll or .so.

      That sorta defeats the purpose of the point I brought up about persistent binary executable compilation.

      print substr("Just another Perl hacker", 0, -2);
      		 - apotheon
      CopyWrite Chad Perrin

[reply]
Re^5: Perl in the Enterprise
by abell (Chaplain) on May 23, 2006 at 15:10 UTC
    ... but something that creates such redundancy by bunding another Perl compiler with every single executable just doesn't really cut it, particularly since it really cuts against the grain for developers who spend so much time trying to eliminate redundant code.
    The issues are quite different: in one case you just waste disk space (maybe as much as a couple mp3's) and maybe a little memory/performance during parallel execution of different programs (since the executables are different and the OS can't cache/share anything); on the other hand, redundancy in code causes problems in maintainability.

    I have no direct experience of perl packagers, but I have used py2exe to pack python programs into self-contained folders (interpreter, libraries and all). When compressed into a self-extracting file, a typical small graphical client takes less than 3 mega (including wxPython). It's very easy to deliver to customers and doesn't require any effort other than "double-click on file, then double-click on executable abc.bat whitin expanded directory".

    Antonio



    The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket
[reply]

In Section Meditations