Compatibility with defined behaviour of variables in another programming language (overflow etc) is another reason, like recently discussed in Trying to translate overflowing JS code to Perl. It might just be easier to load an existing library or interpreter than to recreate all that behaviour in Perl.
Another popular reason is security. I'd rather trust some XS bindings to the always updated and audited OpenSSL library, written by security experts, used by some of the biggest companies in the world) to secure my connections than i would to some pure-perl reimplementation made by a one-person team in their spare time.
Plus, why go to all the hassle of designing a complicated set of Perl modules to, say, implement an interpreter/interface/protocol/crypto library when some nice chaps on the internet have already gone through all the hard parts and gave you a perfectly fine C library with all the trimmings and bugfixes and workarounds. All you have to do is write a nice XS wrapper(*) around it and you're done. Unless the developers of that lib decide to change the interface, you even get all the updates for free ;-)
(*) If you're lucky and the interface is simple enough, h2xs might even do a lot of the work for you. Thumbs up for Perl scripts that writes Perl scripts for you!
In reply to Re^2: XS Modules - why and when?
by cavac
in thread XS Modules - why and when?
by Bod
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |