Someone needs to take jwz aside...

[Nicholas Clark]

On Wed, Apr 20, 2011 at 11:59:33AM +0100, Peter Edwards wrote:

> I had problems installing deps on some antique POS server combined with
> bureaucracy putting me off building my own perl.
> And to be honest, why would I wade through bureaucratic permission-gaining
> exercises when 30 lines of code did the job.
> You'll also note that on a stock company install of Redhat 5.5 last week the
> Moosified version failed to install without my upgrading lwp manually.
> 
> Go ahead and write CPAN modules requiring perl 5.12 and up to date Moose
> then watch organisations throw Perl out the window and replace it with Java.
> Like I'm seeing right now because they end up stuck requiring particular
> versions of libraries to work and rolling upgrades are not company policy or
> are politically inexpedient.
> You can get away that if you're running it on your Macbook or in a small
> central team, good luck on a large corporate platform.

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?


On Wed, Apr 20, 2011 at 12:27:30PM +0100, Andy Armstrong wrote:
> On 20 Apr 2011, at 12:05, Jason Clifford wrote:
> > So how are you handling the requirement to maintain the code doing what
> > those many modules do?
> > 
> > If you are not using a modular approach does that have any impact upon
> > the TCO of maintaining the systems you are deploying?
> 
> Short answer: we're writing most of our new services in Java with a toolchain that makes a lot of dependency management problems go away :)

Which makes me ask the same question. How is Java doing it "right"?

Nicholas Clark