Someone needs to take jwz aside...

[Abigail]

On Wed, Apr 20, 2011 at 07:08:03PM +0100, Joel Bernstein wrote:
> On 20 April 2011 18:45, Pedro Figueiredo <me at pedrofigueiredo.org> wrote:
> > On 20 Apr 2011, at 09:40, Dave Hodgkinson wrote:
> >
> >>
> >> http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/
> >>
> >> Or does he have a point?
> >
> > He might or might not have a point. The truth is, as someone working in a Java shop where the core business is writing games, as long as this happens whenever we need a web server for a non-core service, it's PHP, because Ops don't even have to think about it.
> 
> >From the outside, it looks like the thing that makes PHP apps easy to
> deploy is that they depend only on pure-PHP code they bundle or on the
> standard library - there *is* no dependency chain there.
> 
> > And as for the Java bloat, who cares, it's all packaged nicely and automagically in the JAR, and there's Maven to deal with the dependencies. File size of said JAR doesn't mean squat, we're not on 33.6kbps modems anymore (and please don't mention Shipwright - which I use personally, btw - that still is several orders of magnitude more work than running 'mvn deploy'.
> 
> For *apps*, that's a reasonable approach, while for libraries it adds
> bloat since each library packages its own copy of its common
> dependencies - arguably Java treats this as a feature anyway. In any
> case for the Perl echochamber it's a bug rather than a feature since
> Perl has no ability to load multiple versions of the same module (e.g.
> with lexical scoping taking care of the right module version being
> available for each dependent module), so we're a bit stuck trying to
> distribute modules on this basis and pretend it's not desirable.
> 
> I haven't used it a great deal but PAR lets us distribute apps with
> their dependencies, I don't really know how well it works for
> sysadmins though. There's also App::FatPacker which seems very nice
> (this is what cpanm, perlbrew etc use) but presumably only works with
> pure-Perl dependency chains?
> 
> Essentially, is the issue that it isn't sufficiently easy for Perl
> developers to package applications with their dependencies? What
> doesn't work for a sysadmin if my build ends with a PAR or a fatpacked
> myapp.pl? I can see that you've still got to ensure that the right
> versions of any system libs your PAR contents link to are present or
> expect a segfault, but I suspect Java may not cope well in that
> situation too?


Back in the 90s of the previous century, I worked for a software 
company whose produce needed a bunch of helper/maintainance programs.
They were always written in sh/awk, as "perl doesn't come standard
with the OS [Solaris 2.4/2.5; HP-UX], and we don't want to ask our
customers to install perl".

Installation and upgrading was done in a simple way: everything was
delivered in a single tar-ball, which could be unpacked anywhere on 
the clients system. A single install/update script was run that would
create or modify the database schema. A handful of environment variables 
was all that was needed for user configuration. Including a $COMPANY_TOPDIR
variable.

So, how did I get to write Perl programs instead of shell scripts?
I just compiled perl and put perl and its set of modules in the tarball.
We didn't have a relocatable perl then, but if you just put the directories
where the modules end up in your PERL5LIB environment variable, it doesn't
matter what the directories compiled in are. 

>From then on, we had the option to write Perl programs instead of sh/awk
ones. We'd usually wrapped them inside a shell wrapper:

    #!/usr/bin/sh
    export PERL5LIB=$COMPANY_TOPDIR/path/to/libs
    $COMPANY_TOPDIR/path/to/bin/perl script-to-execute

Easy. The customer doesn't have to have perl (or even know perl is used)
and it gave us full control on which modules (and their versions) will
be there. Full dependency control.


And I've seen the same thing later on. Not with Perl programs, but
applications running in Java. As a consultant, I've seen many servers
running more than one application, each application coming with its 
own java runtime and libraries. No dependency hell. No conflicts between
applications.

I've been trying to tell people for many, many years that this is a good
way to deliver applications, but Perl programmers seem to be stuck in the
60s; and the mere thought of having two copies of a text file takes too
much costly diskspace.



Abigail