Phil Pennock wrote: > On 2008-01-14 at 14:53 -0800, Michael G Schwern wrote: >> Standardized automated installation? What's that? Maybe you get a link to a >> .py file. Maybe you get a tarball and you have to copy the contents by hand. >> Maybe you get a zip file. Maybe you get something that wants to use >> autoconf, Windows users lose. Maybe the link is 404. Maybe it's got a >> Makefile, hard coded with BSD or GNUisms! Maybe it's their "installer of the >> week"! Is it an egg? No, it's 0install! No, wait, it's PyInstaller! Maybe >> you get a link to another web page and you have to scrounge through that to >> find the appropriate download link. Maybe your OS vendor has a package for >> it, but lord knows what patches they've applied or how out of date their >> version is. Maybe you just get an Apache directory listing and you have to >> scroll through to find the latest version. > > Actually sounds similar to the way Perl has been headed with multiple > installers all bickering with each other
Let me count here. One. http://search.cpan.org/dist/ExtUtils-MakeMaker/ Two. http://search.cpan.org/dist/Module-Build/ All the rest use one of those two. And hey, the second one will even automatically create a compatibility wrapper to act like the first! http://search.cpan.org/dist/Module-Build/lib/Module/Build/Compat.pm Two, complete with an emulator, with the maintainer of the first working with and giving their blessing to the second. I'd say that's pretty damn good for 12 years of work. Oddly enough, the problem hasn't been too *many* installers the problem is too *few*. There's been just MakeMaker for so many years that all the installers and people's brains are molded to its every little quirk and detail. Getting the people and the code to accept Module::Build has been an absurdly uphill battle. Every little minor thing it does slightly differently (forget whether it's wrong, just different) gets people kicking and screaming. It's absurd and hateful especially when you know what a fragile, difficult to customize mess MakeMaker is. And most people DO! Hell, I'm even considering an autoconf style emulator just to please package managers that can already speak it. > and all thinking that it's > enough for OS package management to have a manifest in the package > manager's format, with no thought to integrating into version > management. ? > And then there's the threading issue, requiring parallel Perl installs. Abort! Abort! Hate drifting wildly of target! >> And, of course, they're all going to have their own random versioning systems >> so good luck figuring out which one is the latest version. It's probably the >> newest one... but maybe that's an alpha! >> >> So throw your tantrum, put on your little backpack and run away from home! >> You'll get halfway down the block before you come running back! CPAN will >> still be here. > > Just because something is in CPAN that doesn't mean that it's fit for > use. > > I hope I made it clear how much I dislike Python. My point isn't that > Python is better. Heck, this is hates-software. My point is that Perl > has lost its way and can no longer entice me back by not being as messed > up as the others. > > I've already seen the Python side; as I say, I use it at work. I've > also observed how much more there is in the way of quality-controlled > modules that ship with Python, instead of whatever random crud floated > stinkily to the top in the popularity context on CPAN. Ahh, the blessing problem. "It ships with the language, it must be good!" That model slowly breaks down, as we've learned. The stuff that's important today is not the stuff that's important tomorrow... but you can't get rid of it for compatibility reasons. The blessed implementation in the core gets a popularity boost and all the other (possibly better) implementations have to be twice as good to get used and noticed. This tends to kill competition. The crowning example is CGI.pm. It's bloated. It does way too much. It was written over 15 years ago, going all the way back to perl4, so the interface is all wonky. The documentation is tremendous. It has no idea about the web 2.0. For years it has retarded work on better CGI modules because Perl already ships with one, why would you need to look for another? Blessing code freezes one group's decision as to what is best at the time and applies it to everyone. As time moves forward and circumstances change but that decision remains frozen. Perl learned that the hard way, now we only add modules that help to install more modules. Looks like Python is going to learn it the hard way, too. Competition is messy but so is life. It's hateful to think you can write up a spec for it and pick "the best" for everyone. It sure is convenient, and it'll work for a while, but it'll eventually leave you in the dust. > I used to think that documentation was where Perl shone. You called > that out in particular. It's true that Perl's own documentation is > excellent, but the core language only needs to be learnt once and > sometimes be referred back to. > > Many of Perl's modules have excellent docs. These are the modules which > are so common and basic that their equivalent is part of the Python > install. If you're only ever writing to these modules then you're not > really doing much that's not fairly routine monkey coding. > > I finally stopped grumbling about Python only ever having lists of > methods and classes in a fairly raw format in pydoc and the Python > programmers thinking that was enough when I saw which way Perl modules > seem to be going. Crypt::OpenSSL::X509 is a "good" example here. It > doesn't list half the methods or even the relevant constructors; yes, it > lists that you can create an object directly from a file, that doesn't > help if you have the x509 PEM in-memory already. I ended up having to > read the XS source code to find out what methods were and weren't > available and what the parameters were. With automated API interface > lists, at least I'd know about: > Crypt::OpenSSL::X509->new_from_string($pemdata) > without having to delve through HOW NATIVE LANGUAGE CODE IS USED TO > PROVIDE AN INTERPRETED LANGUAGE FEATURE! I shouldn't have needed to > read about ALIAS: and auto-indexes into dispatch tables within Perl for > the aliased names. > > So yes, Perl's documentation was excellent and I could figure all that > out. But no, Crypt::OpenSSL::X509 is not alone here. Shocked! Yes, I am shocked to find that there's poorly documented software out there! Obviously only Perl has this problem. Call us when the honeymoon is over. :) -- Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
