Note: If you don't get the gag, try googling for 'Martin Luther' and '95 theses' or look here.
This really derives from increasing frustration with XS & C code in CPAN modules over the last couple of weeks, followed by a conversation in the CB. Not that I dislike XS per se, the idea of being able to glue in libraries from other programming languages is nice. My personal opinion is that it is overused in CPAN modules, but I'm prepared to be gainsaid on that one. However, I'm constantly finding myself attempting to install modules, following up all the dependencies, and somewhere in the dependency chain XS rises up and bites me.
Yes, perl is written in C. But perl is also shipped, precompiled, with a wide variety of operating systems, which don't necessarily have C compilers installed by default.
Yes, gcc is available for just about every platform imaginable, but not all companies will permit its installation.
Yes, if you're running under windows and the module you want is available from ActiveState, you don't have the compilation problem.
Yes, I know that the language a module is written in is noted on CPAN (assuming that data is up to date) but that doesn't cover the modules dependencies
BUT
If you acquire open source C libraries (openssl for example), you must have access to a C compiler, or they'd be no use to you. Likewise pretty much all other compiled languages. But that isn't true of perl.
My feeling is that any module requiring a C compiler is leaning more towards being an extension to the perl language than being a reusable code library. I'm not suggesting that XS/C modules should be banned, frowned upon or anything like that, just commenting on a perl issue that causes me problems.
The obvious answer is the one suggested to whining travellers in Heinlein's 'The Moon is a harsh Mistress' - "if you don't like it, build your own", and where time allows and there is a need, I'll happily write pure perl versions of existing functionality. But as a passing point if I or anyone else is going to do that, it would be useful to have a standard way of denoting it. For example:
There isn't really a simple solution to the overall problem. For example, recently I needed to encrypt/decrypt passwords. There are pure perl crypt implementations Crypt::Blowfish_PP for example, but Crypt::CBC needs Digest::MD5, which needs C. Of course, Digest::MD5 is often installed as part of a precompiled version now, but on this old version of perl it wasn't installed (I didn't discover Crypt::ECB until later).
So the module dependencies for different modules vary between different versions of perl - there's potentially no such thing as a module which is pure perl in itself and all it's dependencies.
So, thoughts/observations/flames anyone?
Update: Just as a final observation, the title of this node (Nicked from Martin Luther) contains a mention of power. Over at comp.ai.neural-nets, where they're really into their complicated calculations, someone reckoned perl to be 20-30% slower than C for neural nets. I don't think thats so very bad, myself....
Update: I figured this would be contraversial - hence the Luther references. There seems to have been a degree of misunderstanding though. I'm not anti C or anti XS - in fact I use C for other purposes in other environments. XS oftentimes causes me pain because it frequently insists on the same compiler for perl & module though, a limitation that, while I understand it, can present difficulties.
And yes, sometimes a c compiler is not available for whatever reason, and while saying 'thats just stupid' may be true, it doesn't help solve the problem.
Primarily, I was, and am, interested in what other monks have to say on the subject. Thanks to all those who've already replied.
In reply to Disputation of g0n on the power and efficacy of XS by g0n
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |