Someone needs to take jwz aside...
http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point?
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 09:40, Dave Hodgkinson daveh...@gmail.com wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? Key is http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/#comment-90218 P
Re: Someone needs to take jwz aside...
On 20 April 2011 10:03, Paul Makepeace pa...@paulm.com wrote: On Wed, Apr 20, 2011 at 09:40, Dave Hodgkinson daveh...@gmail.com wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? Key is http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/#comment-90218 Must not laugh.
Re: Someone needs to take jwz aside...
On 20/04/2011 09:40, Dave Hodgkinson wrote: Or does he have a point? He completely has a point. CPAN developers right now seem to have a strong predilection for throwing the kitchen sink into modules that really don't need it. (You want to parse dates, you use DateTime. Um, no, not necessarily.) And certainly Moose is not the only way to do object orientation. I agree with him that doesn't seem to be a culture of simplicity.
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 09:40:57AM +0100, Dave Hodgkinson wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? He has a point. --
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 12:05 PM, Simon Cozens si...@simon-cozens.orgwrote: On 20/04/2011 09:40, Dave Hodgkinson wrote: Or does he have a point? He completely has a point. CPAN developers right now seem to have a strong predilection for throwing the kitchen sink into modules that really don't need it. (You want to parse dates, you use DateTime. Um, no, not necessarily.) And certainly Moose is not the only way to do object orientation. I generally agree that bloat happens and perhaps we should think a bit more about that - but I don't think there are any simple solutions. The alternative to having one big, but mostly universal module (like DateTime) is to have many small specialized modules. The problem is that these specialized modules usually still have huge overlap between them - like the many other date time modules or OO frameworks. If your project is complex enough you'll have many of those overlapping specialized modules used there, directly or indirectly - and this can cause more problem then standardizing on a one that would cover all the cases. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: Someone needs to take jwz aside...
On 20 Apr 2011, at 11:05, Simon Cozens wrote: I agree with him that doesn't seem to be a culture of simplicity. Yup - completely agree. This is one of the reasons I like the ::Tiny namespace so much. And the transient dependency explosion - and subsequent burden of updating those dependencies - i.e. the TCO of a Perl app - is the main reason we're not favouring Perl for new applications at the Beeb. -- Andy Armstrong, Hexten
Re: Someone needs to take jwz aside...
On 20/04/2011 11:42, Zbigniew Lukasiak wrote: The alternative to having one big, but mostly universal module (like DateTime) is to have many small specialized modules. No, the alternative is to have the option of either using one big universal module *or* many small specialized modules. A complex project can use the big universal thing and a simple project can just use what it needs. This is a programming principle called modularity.
Re: Someone needs to take jwz aside...
On 20 April 2011 11:13, Jesse Vincent je...@fsck.com wrote: On Wed, Apr 20, 2011 at 09:40:57AM +0100, Dave Hodgkinson wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? He has a point. Gosh that's timely: my talk last week at http://miltonkeynes.pm.org/ Adding OAuth to the BBC World Service Twitter Feeder (Peter Edwards) http://perl.dragonstaff.co.uk/twitter_oauth/ I think the answer (I cannot be bothered to reply on that blog) is to use Net::Twitter::Lite or roll your own like I did there. 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. -Peter http://perl.dragonstaff.co.uk
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 12:42:12PM +0200, Zbigniew Lukasiak wrote: On Wed, Apr 20, 2011 at 12:05 PM, Simon Cozens si...@simon-cozens.orgwrote: On 20/04/2011 09:40, Dave Hodgkinson wrote: Or does he have a point? He completely has a point. CPAN developers right now seem to have a strong predilection for throwing the kitchen sink into modules that really don't need it. (You want to parse dates, you use DateTime. Um, no, not necessarily.) And certainly Moose is not the only way to do object orientation. I generally agree that bloat happens and perhaps we should think a bit more about that - but I don't think there are any simple solutions. The alternative to having one big, but mostly universal module (like DateTime) is to have many small specialized modules. The problem is that these specialized modules usually still have huge overlap between them - like the many other date time modules or OO frameworks. If your project is complex enough you'll have many of those overlapping specialized modules used there, directly or indirectly - and this can cause more problem then standardizing on a one that would cover all the cases. I don't think that was jwz's point. I think his point is: when doing something trivial, don't have a huge dependency chain. Abigail
Re: Someone needs to take jwz aside...
On Wed, 2011-04-20 at 11:48 +0100, Andy Armstrong wrote: Yup - completely agree. This is one of the reasons I like the ::Tiny namespace so much. And the transient dependency explosion - and subsequent burden of updating those dependencies - i.e. the TCO of a Perl app - is the main reason we're not favouring Perl for new applications at the Beeb. 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?
Re: Someone needs to take jwz aside...
On 20 April 2011 11:59, Peter Edwards pe...@dragonstaff.co.uk wrote: 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. *Like* It is frustrating to try to get a recent version of anything at all onto a server that's destined to sit in a data centre for five years, and needs to have a relatively stable install so it won't randomly break ...
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 12:06:27PM +0100, Bill Crawford wrote: On 20 April 2011 11:59, Peter Edwards pe...@dragonstaff.co.uk wrote: 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. *Like* It is frustrating to try to get a recent version of anything at all onto a server that's destined to sit in a data centre for five years, and needs to have a relatively stable install so it won't randomly break ... I don't get this. If it's supposed to be relatively stable, you shouldn't install new things, and there's no need to put something recent of anything at all on it. Or you install new things, which may need an upgrade of other stuff, but if you're installing new stuff the environment isn't relatively stable. Abigail
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 01:01:10PM +0200, Abigail wrote: I think his point is: when doing something trivial, don't have a huge dependency chain. And it's to highlight this that I wrote CPANdeps! -- David Cantrell | Bourgeois reactionary pig There's a hole in my bucket, dear Liza, dear Liza. WHAT MAKES YOU SAY THERE IS A HOLE IN YOUR BUCKET?
Re: Someone needs to take jwz aside...
On 20 April 2011 11:42, Zbigniew Lukasiak zzb...@gmail.com wrote: I generally agree that bloat happens and perhaps we should think a bit more about that - but I don't think there are any simple solutions. The alternative to having one big, but mostly universal module (like DateTime) is to have many small specialized modules. The problem is that these specialized modules usually still have huge overlap between them - like the many other date time modules or OO frameworks. If your project is complex enough you'll have many of those overlapping specialized modules used there, directly or indirectly - and this can cause more problem then standardizing on a one that would cover all the cases. i did see the counterpoint to this a while back when putting in a module to CPAN for $past_employer. Not so much huge dependency chain as there's more than one way to do it being a problem. In this case, all I wanted in the dependencies was insist that a system have the ability to connect via HTTPS, but there are several modules that can provide this, but that's not the way the dependencies work. Because my requirements where actually fairly light, in the end I arbitrarily chose one and made it a requirement, but I still think this wasn't as elegant as it could be. Dominic -- Nonnullus unus commodo reddo is mihi. ABC*D1EFGHIJK2.LMNO3*4PQRST*ITUBE-STANDARD-ANTI-BULLSHEIT-EMAIL*U.56X
Re: Someone needs to take jwz aside...
On 20 April 2011 12:12, Abigail abig...@abigail.be wrote: On Wed, Apr 20, 2011 at 12:06:27PM +0100, Bill Crawford wrote: It is frustrating to try to get a recent version of anything at all onto a server that's destined to sit in a data centre for five years, and needs to have a relatively stable install so it won't randomly break ... I don't get this. If it's supposed to be relatively stable, you shouldn't install new things, and there's no need to put something recent of anything at all on it. Except when there's a bug fix or a new feature in SQL::Abstract or DBIx::Class or the Catalyst runtime (like assigning '' to $c-response-body not having the desired effect, or the session plugin ignoring specified timeouts, or whatever) that you want to have, but it's not been updated on $PlatformOfChoice, ... Or you install new things, which may need an upgrade of other stuff, but if you're installing new stuff the environment isn't relatively stable. If you are able to build one or two .deb packages of needed modules, and install them, and they stay the same for years ... that's still relatively stable. If (as recently happened) you discover a dependency chain that leads to CPAN complaining that you need a newer perl because it's a core module ... it gets extra annoying. Abigail Will
Re: Someone needs to take jwz aside...
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 :) -- Andy Armstrong, Hexten
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 12:27 PM, Andy Armstrong a...@hexten.net 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 :) Well, they go to the java team, if that's what you mean. Meanwhile, those of us working with perl work on an appropriate solution to the problem for our stuff.
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 12:22, Bill Crawford billcrawford1...@gmail.com wrote: If (as recently happened) you discover a dependency chain that leads to CPAN complaining that you need a newer perl because it's a core module ... it gets extra annoying. +1 cpan[1] install Term::ReadLine The most recent version 1.07 of the module Term::ReadLine is part of the perl-5.13.11 distribution. To install that, you need to run force install Term::ReadLine --or-- install F/FL/FLORA/perl-5.13.11.tar.gz Awesome. A development version of perl. Let's see if I can pull in a recent stable perl: cpan[2] install perl Warning: Cannot install perl, don't know what it is. cpan[3] install perl-latest Warning: Cannot install perl-latest, don't know what it is. cpan[4] install perl-stable Warning: Cannot install perl-stable, don't know what it is. cpan[5] install perl-5.14 Warning: Cannot install perl-5.14, don't know what it is. cpan[6] install perl-5.12 Warning: Cannot install perl-5.12, don't know what it is. cpan[7] install perl5.12 Warning: Cannot install perl5.12, don't know what it is. *gives up* Cannot install perl, don't know what it is. Paul
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 12:21:02PM +0100, Dominic Thoreau wrote: i did see the counterpoint to this a while back when putting in a module to CPAN for $past_employer. Not so much huge dependency chain as there's more than one way to do it being a problem. This is why I don't like Catalyst. Sure, it's a nice framework. Trouble is, people abuse it, and they all seem to abuse it in different ways, and each individual abuse seems reasonable at the time. I expect that many of these abuses are the result of not knowing everything there is to know about Catalyst and having to get something working quickly. Of course, a framework where it was only possible to do things in one way would be useless, so we're fucked either way :-) -- David Cantrell | http://www.cantrell.org.uk/david Arbeit macht Alkoholiker
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 12:22:20PM +0100, Bill Crawford wrote: If (as recently happened) you discover a dependency chain that leads to CPAN complaining that you need a newer perl because it's a core module ... it gets extra annoying. That particular bug was fixed a squillion years ago. -- David Cantrell | Official London Perl Mongers Bad Influence Support terrierism! Adopt a dog today!
Re: Someone needs to take jwz aside...
On 20/04/2011 11:59, Peter Edwards wrote: 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. Given that a lot of the push behind the Modern Perl cult is to make Perl more Serious and Enterprise, I find the irony of this deeply delicious. (That is, speaking as someone who only has to deal with Perl when they want to and when it's still fun.)
Re: Someone needs to take jwz aside...
On 20 April 2011 14:18, Simon Cozens si...@simon-cozens.org wrote: On 20/04/2011 11:59, Peter Edwards wrote: 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. Is there anything better in Java? I'm currently looking at the 'zero dependency' java twitter client http://twitter4j.org/. Indeed it's got zero dependencies, but it ships with its own implementation JSON, and OAuth. I bet that if I find one that re-uses some kind of standard JSON and OAuth module instead of re-inventing the wheel, they will also have dependencies. Over the years I was doing Java, I never found the dependencies management being less a hell than with Perl. I don't feel it's wrong for a CPAN package to rely on others that are a de facto standards in the Perl world. J. -- Jerome Eteve. http://sigstp.blogspot.com/ http://twitter.com/jeteve
Re: Someone needs to take jwz aside...
On Wed, 2011-04-20 at 12:27 +0100, Andy Armstrong wrote: 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 :) Does that mean your java team will have to re-invent lots of wheels or will they be using established (and proven) code libraries?
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 15:40, Jason Clifford ja...@ukfsn.org wrote: Does that mean your java team will have to re-invent lots of wheels or will they be using established (and proven) code libraries? They'll probably be using software that doesn't contain a load of '0.x' releases /snark
Re: Someone needs to take jwz aside...
On 20/04/2011 13:29, Paul Makepeace wrote: On Wed, Apr 20, 2011 at 12:22, Bill Crawfordbillcrawford1...@gmail.com wrote: If (as recently happened) you discover a dependency chain that leads to CPAN complaining that you need a newer perl because it's a core module ... it gets extra annoying. +1 cpan[1] install Term::ReadLine The most recent version 1.07 of the module Term::ReadLine is part of the perl-5.13.11 distribution. To install that, you need to run force install Term::ReadLine --or-- install F/FL/FLORA/perl-5.13.11.tar.gz Awesome. A development version of perl. Let's see if I can pull in a recent stable perl: jokeNah, you vape your install and start from scratch - same as PHP!joke Its the only way to ensure an older perl is upgraded cleanly. :-( It gets worse if you want an esoteric build such as thread support etc. Some deps end up unbuildable with say thread support. Messy just does not do it justice. Jacqui p.s. how about listing the depcount for a module. That way we can tell what is truly lite and what is a can-o-worms.
Re: Someone needs to take jwz aside...
On 04/20/2011 04:48 PM, Jacqui Caren-home wrote: p.s. how about listing the depcount for a module. That way we can tell what is truly lite and what is a can-o-worms. You mean like cpandeps does? http://deps.cpantesters.org/ Dave...
Re: Someone needs to take jwz aside...
On 20 April 2011 17:48, Jacqui Caren-home jacqui.ca...@ntlworld.com wrote: p.s. how about listing the depcount for a module. That way we can tell what is truly lite and what is a can-o-worms. something like this http://deps.cpantesters.org/?module=DateTimeperl=latest ? Granted, it would be a benefit to have that in cpan clients.
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 10:40 AM, Dave Hodgkinson daveh...@gmail.com wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? No, code reuse is a *good* thing. Yes, CPAN.pm sometimes fails. Yes, TMTOWTDI means you have to make educated decisions about what is the most *appropriate* way. /Lars
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 06:43:48PM +0200, Lars Thegler wrote: On Wed, Apr 20, 2011 at 10:40 AM, Dave Hodgkinson daveh...@gmail.com wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? No, code reuse is a *good* thing. Sometimes. But I've seen so much code that's needlessly convulated just so it can just some code (or worse, that the code can be reused), that I take the dogma code reuse with more salt than the yearly recommended dosis. Abigail
Re: Someone needs to take jwz aside...
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. 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'. Cheers, Pedro
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 18:01, Abigail abig...@abigail.be wrote: But I've seen so much code that's needlessly convulated just so it can just some code (or worse, that the code can be reused) I think they came up with a term for this back in the '70s: Object Oriented Programming. Paul PS http://en.wikipedia.org/wiki/Object-oriented_programming says This article may be too technical for most readers to understand.
Re: Someone needs to take jwz aside...
On 20 April 2011 18:45, Pedro Figueiredo m...@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? /joel
Re: Someone needs to take jwz aside...
On 20 Apr 2011, at 19:08, Joel Bernstein wrote: On 20 April 2011 18:45, Pedro Figueiredo m...@pedrofigueiredo.org wrote: 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. It's not only that, it's more that to get a fully-featured PHP environment, the server build script reads yum install apache yum install php Get to that point with Perl and you win. I wrestled with this a couple of years ago (even gave a talk about it at YAPC::EU, http://www.slideshare.net/pfig/perl-in-teh-cloud) and it's really a lot of work, every time you need to update something, you either a) rebuild the AMI b) update the snapshot which your EBS volumes are based on c) fiddle with your local::lib install or Shipwright vessel. You know what I do with Maven? I update the version number in the file that drives it. Boom. I have got to the point with Maven where I can have it run tests and drive CI of Perl modules and apps, but I simply don't have the time to make it grok Perl to the point of dealing with dependencies, etc. 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 - No they don't. 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? The problem lies well below this: vendor-supplied Perls are shit, so you always have to work with your own. 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? Funny you should say that, I can't remember a single instance of having to have a given external (e.g., C) library in a box to run our Java stack (and we use quite a lot of 3rd-party Java libraries). Cheers, Pedro
Re: Someone needs to take jwz aside...
Abigail wrote: On Wed, Apr 20, 2011 at 06:43:48PM +0200, Lars Thegler wrote: On Wed, Apr 20, 2011 at 10:40 AM, Dave Hodgkinsondaveh...@gmail.com wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? No, code reuse is a *good* thing. Sometimes. But I've seen so much code that's needlessly convulated just so it can just some code (or worse, that the code can be reused), that I take the dogma code reuse with more salt than the yearly recommended dosis. Especially when the code reuse in this case is JUST to get access to strptime. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 07:08:03PM +0100, Joel Bernstein wrote: On 20 April 2011 18:45, Pedro Figueiredo m...@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
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 09:40:57AM +0100, Dave Hodgkinson wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? He's embarrassed that didn't think to run apt-get install libnet-twitter-perl?
Re: Someone needs to take jwz aside...
On 20 April 2011 20:51, Abigail abig...@abigail.be wrote: 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. I replied to someone on dbix-class list this week how to install multiple perl/libs/libarry trees including system libraries (i.e. C, C++) and be able to build new servers easily http://lists.scsys.co.uk/pipermail/dbix-class/2011-April/009891.html And of course Piers Cawley has done some great work at the BBC on automating This Sort Of Thing. Credits also to Steve Mynott who proved g4l works great for bulk imaging of Linux distro configs for new machines when he built a new cluster of app and database servers for our department recently. Thinking about it I didn't mention pkgsrc for system libraries. It's pretty good although it can whack you in the back of the head as a colleague found out when building our dev machine subversion and then suddenly the client-side developers started getting shareable library errors :-} Regards, Peter http://perl.dragonstaff.co.uk
Re: Someone needs to take jwz aside...
On 20 April 2011 22:53, Walt Mankowski walt...@pobox.com wrote: On Wed, Apr 20, 2011 at 09:40:57AM +0100, Dave Hodgkinson wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? He's embarrassed that didn't think to run apt-get install libnet-twitter-perl? Fails on Redhat Linux, need to run yum. What if he needs a newer version of the library and the upstream package provider hasn't bundled it yet? Imagine you're supporting a 3 year old code base that needs specific versions of DBIx::Class, Catalyst, Moose and Class::MOP to make it run, and when you do a upgrade via yum or apt-get or cpan random things break in your regression tests and you don't have the budget to go fix all of them. (No, that's not where I work now but it is a real world situation.) -Peter
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 05:53:20PM -0400, Walt Mankowski wrote: On Wed, Apr 20, 2011 at 09:40:57AM +0100, Dave Hodgkinson wrote: http://www.jwz.org/blog/2011/04/a-badge-for-the-software-industrys-failures/ Or does he have a point? He's embarrassed that didn't think to run apt-get install libnet-twitter-perl? That doesn't work so well on a vanilla OS X box. Whcih is what his workstation is. There is a toolchain bug. Perl's toolchain can't find XCode. --
