On Wed, Apr 27, 2011 at 01:28:14PM +0100, Pedro Figueiredo wrote: > On 27 Apr 2011, at 13:02, Nicholas Clark wrote: > > > > > The issues seem to be dependency management and code reuse. > > > > How is Java solving these in ways that Perl is failing at? > > > > It's not automating the (to some degree necessary) bureaucratic > > permission-gaining exercises. So what is it doing differently? > > > > >From my point of view, when we decide to update a dependency, run the tests, > >get Ops approval, have run it on a few live servers, etc (the whole > >bureaucratic process), all I have to do is update or add the dependency > >information in the POM file: > > <dependency> > <groupId>mysql</groupId> > <artifactId>mysql-connector-java</artifactId> > <version>5.1.13</version> > <scope>compile</scope> > </dependency> > > I would either add this block, if it's a new dependency, or change the > version number. Then I would run 'mvn deploy' and go have a coffee.
But a dependency in a Makefile.PL can do that just as well, so what's the difference/advantage of the Java toolchain? As a partial answer, most everywhere I've worked has *not* packaged up its internal code as modules with Makefile.PL - it's just one (or more) big trees of modules in place. Is the "problem" that the compile first nature of Java forces one to package everything up within a build system (a sunk cost, which can't be avoided, unlike perl), so that it's always going to be a low *incremental* cost to add proper dependency metadata to a Java project? > Ops aren't even involved in this other than to deploy the new package (a > single file) to live and having given their amen to the results of the > previous testing. Is that the *big* advantage - process? In that it's standard, reliable and easy to distribute java code as a single file, that's known good to work? Meaning that a lot of the process cost of installing dependencies can be pushed back from "operations" to "development", meaning in turn that operations are not as averse to changing/adding new code, because for them it's pretty-much a no brainer? [Whereas you can't usefully compile a single perl module or distribution into a single file package that the runtime only needs to load and link-edit into the rest of the code, and I think that it's a "hard" problem to solve because a: Perl can run code at compile time, thanks to BEGIN {} blocks b: Perl code is happy/allowed to fiddle with anyone else's namespaces, including globals, so it's hard to know what the actual impact of C<use Foo> really was neither of which, I believe, is the case for Java. Plus, c: The relative ease of XS, and the things it lets you that you can't in pure Perl means that it's fairly common to end up indirectly depending on an XS module. Which is fine locally, but means that your remote deploy is now (at least) 2 things - the Perl code, the shared object from the XS code, and then potentially any dependencies on other shared objects. whereas, for Java, nearly everything is written in pure Java, and deployed as Java bytecode?] And what of this can't be solved by building packages for the OS packaging system? Which boxes *don't* those tick that Java does? Nicholas Clark