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

I basically agree with everything you've said (at least, everything with which I've enough familiarity to be able to come to a reasonable conclusion), with one exception: I'm convinced of another benefit to "native compilation" (meaning persistent binary executable compilation, of course).

This is really a social benefit, rather than a technical benefit, though it is a technical side-effect that creates this benefit. In particular, I refer to portability. I don't mean portability across platforms, but across implementations of a single platform, via end-users. End-users like having an "installer" that creates an executable program without attendant dependencies. That's often largely irrelevant for Perl on Linux, but highly relevant on Windows systems, where Perl parsers are a rare beast indeed (amongst poplations of people who aren't Perl programmers, at any rate). The ability to simply and easily produce a persistent binary executable that requires no installed parser (or modules/libraries specific to it, for that matter) has I think been a significant advantage for the universalization of C/C++, and the marketing drive to get JVMs of various descriptions installed on every workstation, server, laptop, toaster, and dead badger on the planet by Sun has mitigated this social shortfall for Java enough to overcome that barrier to widespread use of applications developed in that language. Until something written in Perl can be downloaded, one-click "installed", and run on an otherwise "bare bones" MS Windows install (or until MS Windows isn't the default end user OS), we aren't going to see Perl enjoying the same popularity as certain other languages.

The easiest way to achieve that, I think, is to suddenly sprout a compiler of persistent binary executables for Perl.

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

Replies are listed 'Best First'.
Re^3: Perl in the Enterprise
by tsee (Curate) on May 20, 2006 at 08:42 UTC

    While Perl doesn't offer compilation to bytecode (before execution), it is possible to create stand-alone applications by packing all resources in a self-contained, executable archive.
    Of course, I am talking about the PAR module here (Homepage, CPAN).

    Now, it is a little rough around the edges here and there, but it's actively maintained and I have personally used it with large applications in enterprise environments.

[reply]

      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

[reply]

        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]
        ... 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