in reply to Re: Disputation of g0n on the power and efficacy of XS
in thread Disputation of g0n on the power and efficacy of XS

I think part of g0n's point is just the pain of getting the external libraries. For example, I'm attempting to get XML::Parser compiled on an AIX box to get XML::Twig to work. Now I have to track down Expat for AIX because, of course, Expat isn't included with XML::Parser.

I may be misinterpreting the original post, but that's one point I read from it.

  • Comment on Re^2: Disputation of g0n on the power and efficacy of XS

Replies are listed 'Best First'.
Re^3: Disputation of g0n on the power and efficacy of XS
by brian_d_foy (Abbot) on Apr 21, 2005 at 03:23 UTC

    Those things have never seemed especially hard for me. Just how easy do you want things to be?

    I'm not sure why you have to track down expat: it's not tough to find. There are even binaries for AIX (which I found by Googling "expat AIX" and following the top link).

    I'd rather not have expat as part of XML::Parser. I'll download the latest version and compile it myself. The current version of expat doesn't have to get out of step with the one that would get locked in with a version of XML::Parser. I can even update them separately.

    Installing libraries isn't that hard, and installing a C compiler isn't that hard (although it can be lengthy). Distributing them with the modules isn't going to make that any simpler.

    The original post complains that we even deign to use something written in C, and correctly says that if you don't like it, you can upload the pure Perl version to CPAN. I'd rather just use what other people have already than reinvent the wheel. :)

    --
    brian d foy <brian@stonehenge.com>
[reply]

      I think you're missing the point. The point is, when I have two dozen XS-based modules to install on multiple machines, especially of different architecture (Windows, Unix, Linux, Mac, mainframe) where each architecture comes with different levels of different supporting code (if it comes with it at all, e.g., Linux comes with expat, but AIX doesn't), that's a lot to pull together. Yes, it can be done. It's just a reasonable amount of effort to do.

      And then you get situations where you have to fight a beaurocracy to get it done on hundreds of machines that you don't otherwise even have access to, but they need something to use the perl software you wrote depending on it (directly or indirectly). Not that this is incredibly different if we were to be writing in C - depending on expat is depending on expat. However, there are way more people who understand C/C++ limitations and are willing to work with them than there are for perl - so it's just a struggle.

      And, of course, in C/C++, I find people are often less willing to reuse existing code, preferring to reinvent wheels. So then the issue doesn't come up as often.

[reply]

        I'm not missing the point: I just don't agree with yours. There's a difference.

        You have to install software on a bunch of different architectures, machines you don't have access to, and you have to fight a bureaucracy. I don't see how any of those problems are solved by anything we're talking about. You still have to install software on a bunch of different machines of different architectures and you still have to deal with the bureaucracy.

        I've been in that situation, and I always had CDs with all the binaries I needed. I compiled everything I needed and then I had it. Installing it on one machine or a hundred made no difference to me. Finding popular libraries is very easy, finding binaries of them is very easy, and in most cases compiling them is five minutes of work to get the thing going. After that, it doesn't matter if it's Perl or C or Java or anything else: you still have to push it to all the machines.

        I wouldn't keep around a sysadmin who couldn't do this easily, and I certainly wouldn't tolerate any whining about it being too much work when I know it's not. This is not the sort of problem that a good sysadmin seriously complains about.

        So, you have a tough job, and you know Perl. Let's see some code that solves it. Perl's all about making the hard things possible, so the people who keep complaining about hard things just aren't trying.

        --
        brian d foy <brian@stonehenge.com>
[reply]

      expat isn't a hard find, but it'd be possible that other modules may use more obscure programs, which may not be available as source, or may be outdated and not compile under the compiler suite that you have available.

      I wouldn't mind seeing better use of the DSLIP codes when searching CPAN, or for there to be a more consistent way for there to be checking in Makefile.PL to verify non-perl dependancies. Of course, it would be difficult to determine the versions of any non-perl requirements. (which I got stung on just last week -- Astro::FITS::CFITSIO requires cfitsio. I didn't think it a problem to install cfitsio through darwin ports. One of the tests failed for Astro::FITS::CFITSIO. After much frustration, I did a little searching, and stumbled across the main site for Astro::FITS::CFITSIO, which mentions:

      NOTE: version 2.500 of the cfitsio library is required.

      No where is this mentioned in the POD for Astro::FITS::CFITSIO. (and of course, darwin ports had an earlier version)

      expat is just the tip of the iceburg. Other modules may contain dependancies on Fortan, like cfitsio, or other languages, that might make it otherwise more complicated to install. It'd be nice for those modules that are just perl wrapped around another program, for there to be a way to find something that is a pure perl implementation, especially when you're trying to debug interaction issues. (eg, Mozilla::LDAP vs. Net::LDAP)

[reply]

In Section Meditations