Someone needs to take jwz aside...

Joel Bernstein joel at
Wed Apr 20 19:08:03 BST 2011

On 20 April 2011 18:45, Pedro Figueiredo <me at> wrote:
> On 20 Apr 2011, at 09:40, Dave Hodgkinson wrote:
>> 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 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?


More information about the mailing list