Re: Someone needs to take jwz aside...
On Fri, Jun 10, 2011 at 09:10, James Laver london...@jameslaver.com wrote: I'm actually liking it more than CPAN for publishing and installing stuff. The only weak area is lack of search.cpan.org. Why is search.cpan.org code (still) not open source? P
Re: Someone needs to take jwz aside...
On Fri, Jun 10, 2011 at 10:10:33AM +0100, Paul Makepeace wrote: On Fri, Jun 10, 2011 at 09:10, James Laver london...@jameslaver.com wrote: I'm actually liking it more than CPAN for publishing and installing stuff. The only weak area is lack of search.cpan.org. Why is search.cpan.org code (still) not open source? Because Graham hasn't opened it. -- David Cantrell | Nth greatest programmer in the world In My Egotistical Opinion, most people's ... programs should be indented six feet downward and covered with dirt. --Blair P. Houghton
Re: Someone needs to take jwz aside...
Simon Wistow wrote: On Wed, Jun 08, 2011 at 10:57:56AM -0400, Matt Sergeant said: I'm actually liking it more than CPAN for publishing and installing stuff. The only weak area is lack of search.cpan.org. My problem with npm is that it either tries to install stuff in some random directory in my home directory or suggests, with a straight face, that I chown -R $USER /usr/local I think that has changed now with 1.0. Every install is into the current directory now. I think you'll find it is pretty close to bundler now. Though the documentation is still lacking. One really nice thing I like is if you're working on a project, you put your dependencies into the package.json in your project directory, and then just type npm install and it pulls in those dependencies automatically and makes them available to that project (and only that project). 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, Jun 8, 2011 at 11:21, David Cantrell da...@cantrell.org.uk wrote: Of course, it's possible that the Comprehensive Python Archive Network or similar for ruby/javascript/java/C/whatever does exist but I just can't find it. But then, if I can't find it, it's not much use. (If you were a python programmer and yet had still somehow managed to assiduously avoid all mentions of it, you could search for 'python packages' (because that's what they're called in python) and would find the top result is http://pypi.python.org/pypi) Paul
Re: Someone needs to take jwz aside...
On Wed, 2011-06-08 at 12:07 +0100, Paul Makepeace wrote: On Wed, Jun 8, 2011 at 11:21, David Cantrell da...@cantrell.org.uk wrote: Of course, it's possible that the Comprehensive Python Archive Network or similar for ruby/javascript/java/C/whatever does exist but I just can't find it. But then, if I can't find it, it's not much use. (If you were a python programmer and yet had still somehow managed to assiduously avoid all mentions of it, you could search for 'python packages' (because that's what they're called in python) and would find the top result is http://pypi.python.org/pypi) As helpfully documented here: http://wiki.python.org/moin/MovingToPythonFromOtherLanguages signature.asc Description: This is a digitally signed message part
Re: Someone needs to take jwz aside...
On Wed, 8 Jun 2011, David Cantrell wrote: It's the lack of a CPAN-a-like for any other language that keeps me coming back to perl. Of course, it's possible that the Comprehensive Python Archive Network or similar for ruby/javascript/java/C/whatever does exist but I just can't find it. But then, if I can't find it, it's not much use. Python repo http://pypi.python.org/pypi It was fairly chastening a couple of years back looking for a library implementing Role Based Access Control and finding that there was a Python one but no Perl one http://pypi.python.org/pypi?%3Aaction=searchterm=role+based+access+controlsubmit=search http://search.cpan.org/search?query=role+based+access+controlmode=all Then when I was doing WxWidgets programming from ActivePerl having to use the wxPython library docs http://www.wxpython.org/ because they were more up to date and complete than the Perl ones http://wxperl.sourceforge.net/documentation.html in terms of calling from a wrapper (more useful than the C++ docs). Node.js repo http://npm.mape.me/ V8 seems to work well on Unix and takes little code to implement an event-driven networking app using server-side JS. If you can get over the 'Nam-style flashbacks to old skool javascript hacks for IE5.0 Regards, Peter http://perl.dragonstaff.co.uk
Re: Someone needs to take jwz aside...
Hakim Cassimally wrote: While Javascript-the-language is lovely (as you say, better in some respects, worse in others, than Perl), that's only one part of the story. I've not followed Javascript-the-platform that closely (i.e. anything much beyond jQuery) - what's your experience been like, working with Node and other libraries? It's ok. The standard library shipping with node is lacking in areas (there's no flock(), there's no getopts parser, and a bunch of other things), and right now it feels like it is stagnating while they get in true Windows support, but I've been surprised by the breadth of things available on npm (the equivalent of cpan). Perl-Javascript is a really interesting migration path I'd not considered, and I'm not sure it's faster! would convince me on its own -- we all know there are faster languages than Perl. But... JS does have a significant advantages over, say, Perl-Haskell, as Javascript is so widespread and therefore has many(devs, projects, jobs). OK let me put it another way than just faster - it's the fastest option for dynamic languages (with the possible exception of Lua-JIT) that has a sane (ALGOL-style) syntax, while still having a large user base. My thinking behind Haraka is that a lot of web sites need a mail server with custom functionality, and their web site coders know Javascript, so why not provide them with an option to do stuff in JS for email. Also the other huge thing for me is I've been writing async code in Perl now for years, and you always come across fighting with some library because it's got a blocking API so either you can't use it, or you take a risk and block the event loop while it runs (the same is true for Twisted or the Ruby one). That just doesn't happen in Node - everything is async. 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...
David Cantrell wrote: It's the lack of a CPAN-a-like for any other language that keeps me coming back to perl. Of course, it's possible that the Comprehensive Python Archive Network or similar for ruby/javascript/java/C/whatever does exist but I just can't find it. But then, if I can't find it, it's not much use. http://npmjs.org/ I'm actually liking it more than CPAN for publishing and installing stuff. The only weak area is lack of search.cpan.org. Note that this is for Node.js stuff only - not Javascript in general. __ 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...
Simon Cozens wrote: On 02/06/2011 21:50, gvim wrote: Considering the amount of development you've done on Perl web frameworks over the years isn't this tantamount to having given up on Perl, at least for web development? Yes and no. I've moved from being more of a developer to being more of a user. Perl is a fantastic language for developers. It has a great culture for developers. We're all brilliant at producing tools which other developers can pick up and do really great stuff with. Perl is wonderful if I want to write my own web framework, or construct my own CMS on top of one of the hundreds of Perl web frameworks which already exist. As someone else who has written a bunch of popular perl stuff over the years, I'll chime in here too - I write a lot less open source stuff these days, but when I do I'm looking much more to JavaScript. The language is actually about as good as Perl (some areas better, some worse), but the implementation, the interpreters, are just WAY faster. https://github.com/baudehlo/Haraka Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
failing to steal from Java (was Re: Someone needs to take jwz aside...)
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
groupIdmysql/groupId
artifactIdmysql-connector-java/artifactId
version5.1.13/version
scopecompile/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
Cuse 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
Re: Someone needs to take jwz aside...
On 21/04/2011 09:38, Simon Cozens wrote: On 21/04/2011 09:26, Mark Overmeer wrote: CPAN was never made to maintain software. It is made to distribute software. When you upload something to it, there is no warning that you will become responsible for its future. And this, folks, is precisely why I use Drupal these days. Considering the amount of development you've done on Perl web frameworks over the years isn't this tantamount to having given up on Perl, at least for web development? gvim
Re: Someone needs to take jwz aside...
On 02/06/2011 21:50, gvim wrote: Considering the amount of development you've done on Perl web frameworks over the years isn't this tantamount to having given up on Perl, at least for web development? Yes and no. I've moved from being more of a developer to being more of a user. Perl is a fantastic language for developers. It has a great culture for developers. We're all brilliant at producing tools which other developers can pick up and do really great stuff with. Perl is wonderful if I want to write my own web framework, or construct my own CMS on top of one of the hundreds of Perl web frameworks which already exist. But these days I don't. I don't have infinite amounts of time to enjoy fiddling with programming. I just want to get stuff done. Most of the time, I want applications, not libraries. Perl culture is wonderful if I want to build my own CMS, but not all that wonderful if I just want to use one, because we're all writing for other developers and not necessarily for end users. When it comes to a fairly customizable site that I can throw up pretty quickly and start editing content on, then Drupal blows away... well, I don't even know what. Bricolage? WebGUI? Moveable Type is probably the closest equivalent, and it isn't particularly equivalent. Yes, sure, I could write one, and I haven't, so in that sense, yeah, I've given up on Perl. But the reason I haven't written one is that Drupal does what I want, and I don't actually care what technology it's built on so long as it works, and to imagine that I ought to reinvent that particular wheel just out of some strange loyalty to Perl is to miss the point that a programming language is a tool, not an end in itself - once again ignoring what the end user cares about. I still code, and when I code, I still code in Perl. So in that sense, no, I haven't given up on Perl. But at the same time, I'm not remotely interested in making Perl the greatest all-singing all-dancing language there is with nice carbon copies of all the other applications out there; I'm *happy* to use Perl in a tool-smithing, glom-modules-together way because that's what it's good at. *Really* good at. If I am developing new code, I find that really useful. I mean it, Perl does have a great culture for developers. But for end-user stuff, I'll use whatever tools I find available to get the job done. There is, after all, more than one way to do it.
Re: Someone needs to take jwz aside...
On Wed, Apr 27, 2011 at 8:17 PM, Pedro Figueiredo m...@pedrofigueiredo.orgwrote: If only it knew how to manage a Shipwright vessel... So, I was gonna ask. Does Shipwright do most of what we like about Maven? Would it be that hard to define a list of modules, a Perl version, and let something driving Perlbrew just get stuck in to it? I could see that being an issue for mod_perl apps, but for other stuff? Some Perl modules need compiling, which again, throws a spanner in the works, but...? -P
Re: Someone needs to take jwz aside...
On Thursday, April 28, 2011, Simon Cozens si...@simon-cozens.org wrote: On 27/04/2011 17:19, Avleen Vig wrote: That's right. If you want OO, you can always use a real programming language. Well, you're either using Smalltalk, or faking it. Usually badly. Moose is faking CLOS though. Sort of.
Re: Someone needs to take jwz aside...
On Thu, Apr 28, 2011 at 4:04 AM, Simon Cozens si...@simon-cozens.orgwrote: On 27/04/2011 17:19, Avleen Vig wrote: That's right. If you want OO, you can always use a real programming language. Well, you're either using Smalltalk, or faking it. LISP, or go home. http://xkcd.com/224/
Re: Someone needs to take jwz aside...
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
Re: Someone needs to take jwz aside...
On 27 Apr 2011, at 13:02, Nicholas Clark wrote: Which makes me ask the same question. How is Java doing it right? In my limited BBC experience, mvn just pulls freshest everything down from the repo...
Re: Someone needs to take jwz aside...
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 groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.13/version scopecompile/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. 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. Cheers, Pedro
Re: Someone needs to take jwz aside...
On 27 Apr 2011, at 13:15, Dave Hodgkinson wrote: On 27 Apr 2011, at 13:02, Nicholas Clark wrote: Which makes me ask the same question. How is Java doing it right? In my limited BBC experience, mvn just pulls freshest everything down from the repo... No, it pulls whatever you tell it to pull.
Re: Someone needs to take jwz aside...
On 27 Apr 2011, at 13:29, Pedro Figueiredo wrote: In my limited BBC experience, mvn just pulls freshest everything down from the repo... No, it pulls whatever you tell it to pull. This explains the gist of what Maven does. http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html -- Andy Armstrong, Hexten
Re: Someone needs to take jwz aside...
On 27 Apr 2011, at 13:51, Andy Armstrong wrote: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html As far as dependency management goes. It does so much more than that. I'd go for the by example book for a quick overview, and then use the reference to find more details: http://www.sonatype.com/books.html Also, http://maven.apache.org/users/index.html and http://maven.apache.org/plugins/index.html --- there be gold in them hills! These days I manage everything with Maven, from Java apps to a Map/Reduce framework to shell scripts and presentations, and obviously our CI. It's removed so much hassle from my work day I'm even glad to put up with it sometimes having to download half of the internet. If only it knew how to manage a Shipwright vessel...
Re: Someone needs to take jwz aside...
On Wed, Apr 20, 2011 at 5:05 AM, 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. That's right. If you want OO, you can always use a real programming language.
Re: Someone needs to take jwz aside...
On 20/04/11 23:17, Peter Edwards wrote: 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.) Which is a pretty serious indictment of CPAN and the attitudes of the people that maintain software there. How can anyone expect businesses to use perl and CPAN when stuff is likely to break (sometimes big time) when one upgrades the toolchain? Why does stuff on CPAN so frequently not maintain backward compatibility? Dirk
Re: Someone needs to take jwz aside...
* Dirk Koopman (d...@tobit.co.uk) [110421 08:08]: On 20/04/11 23:17, Peter Edwards wrote: 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.) Which is a pretty serious indictment of CPAN and the attitudes of the people that maintain software there. CPAN was never made to maintain software. It is made to distribute software. When you upload something to it, there is no warning that you will become responsible for its future. In my experience, any upgrade will cause some headeach. Not only upgrades of Perl modules. Gladly there are regression tests to warn you at an early stage. How can anyone expect businesses to use perl and CPAN when stuff is likely to break (sometimes big time) when one upgrades the toolchain? One of the weak points of CPAN is that you can only install the latest version of a module. One of the reasons for that is the 02packages list which is used to figure-out which distribution (tar.gz) is needed for a certain module (pm). There can only be one dist per pm. So, you need to set-up your own local archive using cpanmini or cpansite with the versions you prefer on your systems. Or: fix the versions of the yum/apt packages you get installed by collecting those yourself... Open Source tends to say last is best, where serious system administrators say: everywhere the same is best. Why does stuff on CPAN so frequently not maintain backward compatibility? You do not only have to take care about your own code, but also about Perl and about the code of all dependencies. Cpantesters helps a lot, but only after you have uploaded a broken version. As demonstration of cpan6, I have created a full backpan archive, where you can get the 02packages of any day in history. So you can then say install DBIx::Simple with the knowledge of 2001-02-12 as yum Large parts of the code is ready... still needs a few days work. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Someone needs to take jwz aside...
On 21/04/2011 09:26, Mark Overmeer wrote: CPAN was never made to maintain software. It is made to distribute software. When you upload something to it, there is no warning that you will become responsible for its future. And this, folks, is precisely why I use Drupal these days.
Re: Someone needs to take jwz aside...
On Wed, 2011-04-20 at 23:06 -0400, Jesse Vincent wrote: 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. That's not a perl fail but rather a fail on the part of those who package (or don't package) perl modules for that platform. In fairness it's also a fail on the various Linux platforms I've encountered too as nobody has, so far, produced a comprehensive cpan to $whatever_distro repository There is a toolchain bug. Perl's toolchain can't find XCode. Is it really the responsibility of the perl toolchain to do that? Surely it's a platform responsibility to provide a reliable dependency chain whether the platform is an OS distro or something else.
Re: Someone needs to take jwz aside...
On 21/04/2011, at 7:08 PM, Jason Clifford wrote: On Wed, 2011-04-20 at 23:06 -0400, Jesse Vincent wrote: 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. That's not a perl fail but rather a fail on the part of those who package (or don't package) perl modules for that platform. In fairness it's also a fail on the various Linux platforms I've encountered too as nobody has, so far, produced a comprehensive cpan to $whatever_distro repository I'm not sure what all the fuss is about. I've spent a fairly small amount of time lately packaging up perl applications for 4 or 5 different operating systems, on systems with varying degrees of security (ie. from apps that need root, to locked down windows workstations and uncooperative admins). On a unixy system, grabbing the latest stable perl, and compiling a relocatable binary is the go. After that either update $PATH or call the perl binary explicitly and install cpanminus is by far the lowest friction strategy. The only trouble I've had with this approach is Alien::SVN's insistence that it compiles binaries to /usr/lib. If I didn't have root on that system I would have been more annoyed. Oh and some module was broken in version 0.45 in linux, so I bisected old versions, and it turned out that version 0.44 installed OK, so I shoved a comment in the Makefile.PL, and in INSTALL.pod. The fact that admins will be expanding an archive rather than having to go through the install machinations themselves makes the inconvenience minor. On windows, strawberry portable perl is the go. Just like the unix version except much slower (at least on the VMs I use, and the ludicrously underpowered/small disk space workstation that $employer[0] gives me). Does anyone have a .bat file handy that will strip out all the toolchain stuff for deployment? And if you're so inclined you can keep your ~/perl install in a git repository, and while there's some overhead to this, it's a handy way to annotate what you've been doing with your perl. Of course I don't do sysadmin type stuff. If I did I'd be using the system perl, pure perl modules and App::FatPacker (oh and Path::Class). However, none of this is a solution for your management problems. Leave the system perl for the system and the system will leave perl up to you.
Re: Someone needs to take jwz aside...
On Thu, Apr 21, 2011 at 10:38 AM, Simon Cozens si...@simon-cozens.org wrote: On 21/04/2011 09:26, Mark Overmeer wrote: CPAN was never made to maintain software. It is made to distribute software. When you upload something to it, there is no warning that you will become responsible for its future. And this, folks, is precisely why I use Drupal these days. Do they make any guarantee like that? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: Someone needs to take jwz aside...
On Thu, Apr 21, 2011 at 10:08:16AM +0100, Jason Clifford wrote: On Wed, 2011-04-20 at 23:06 -0400, Jesse Vincent wrote: There is a toolchain bug. Perl's toolchain can't find XCode. Is it really the responsibility of the perl toolchain to do that? Yes. FWIW, it has managed to find XCode just fine on all my machines. Maybe this is a recently introduced bug, or some new version of XCode does things differently. -- David Cantrell | Enforcer, South London Linguistic Massive There is no one true indentation style, But if there were KR would be Its Prophets. Peace be upon Their Holy Beards.
Re: Someone needs to take jwz aside...
On Thu, Apr 21, 2011 at 10:26:45AM +0200, Mark Overmeer wrote: As demonstration of cpan6, I have created a full backpan archive, where you can get the 02packages of any day in history. So you can then say install DBIx::Simple with the knowledge of 2001-02-12 as yum Large parts of the code is ready... still needs a few days work. See also http://cpxxxan.barnyard.co.uk/ -- David Cantrell | top google result for topless karaoke murders Godliness is next to Englishness
Re: Someone needs to take jwz aside...
On Thu, 2011-04-21 at 10:26 +0200, Mark Overmeer wrote: As demonstration of cpan6, I have created a full backpan archive, where you can get the 02packages of any day in history. So you can then say install DBIx::Simple with the knowledge of 2001-02-12 as yum That sounds really useful! signature.asc Description: This is a digitally signed message part
Re: Someone needs to take jwz aside...
On Thu, Apr 21, 2011 at 12:33:52PM +0100, David Cantrell wrote: On Thu, Apr 21, 2011 at 10:08:16AM +0100, Jason Clifford wrote: On Wed, 2011-04-20 at 23:06 -0400, Jesse Vincent wrote: There is a toolchain bug. Perl's toolchain can't find XCode. Is it really the responsibility of the perl toolchain to do that? Yes. FWIW, it has managed to find XCode just fine on all my machines. Maybe this is a recently introduced bug, or some new version of XCode does things differently. Jamie swears that it's a vanilla vendor Perl on a new 10.6.7 box with XCode 4. Someone spotted it trying to use the _ppc_ compiler at some point during the build. I don't currently have suitable test hardware to try to repro it on. :/
Re: Someone needs to take jwz aside...
On 21 Apr 2011, at 12:37, Denny wrote: On Thu, 2011-04-21 at 10:26 +0200, Mark Overmeer wrote: As demonstration of cpan6, I have created a full backpan archive, where you can get the 02packages of any day in history. So you can then say install DBIx::Simple with the knowledge of 2001-02-12 as yum That sounds really useful! Isn't CPAN on Time Machine?
Re: Someone needs to take jwz aside...
* Dave Hodgkinson (daveh...@gmail.com) [110421 12:13]: install DBIx::Simple with the knowledge of 2001-02-12 as yum Isn't CPAN on Time Machine? No. But we have backpan, where all the modules ever uploaded are kept. The main problem is that the administration 02packages (etc) files which are used during installations have not been preserved. It is very hard to get them back correctly, where you may find name-space conflicts. The first to use a namespace wins. So, to regenerate the index files correctly, you have to replay CPAN insert (pause) from its origin... It has also not been tracked which modules where removed from CPAN because of copyright problems and such. The whole archive lives in a current situation only mood. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Someone needs to take jwz aside...
On 21 Apr 2011, at 12:52, Jesse Vincent wrote: Jamie swears that it's a vanilla vendor Perl on a new 10.6.7 box with XCode 4. Someone spotted it trying to use the _ppc_ compiler at some point during the build. I don't currently have suitable test hardware to try to repro it on. :/ Could it be related to this? http://transfixedbutnotdead.com/2010/01/24/mac-os-x-snow-leopard-10-6-and-perl/ (I use the 32-bit version, without problems) Cheers, Pedro
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. --
