Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^2: Pure Perl Modules, XS Modules, what's the current trends?

by skazat (Hermit)
on Dec 20, 2007 at 21:22 UTC ( #658271=note: print w/ replies, xml ) Need Help??


in reply to Re: Pure Perl Modules, XS Modules, what's the current trends?
in thread Pure Perl Modules, XS Modules, what's the current trends?

Low version numbers don't mean a thing, nor does it matter how long ago something has been hacked on (unless you are talking like +5-6 years,

It is hard to distinguish between Production Ready and not, without signifiers, like version numbers that are above, "1", or something like that. There's always the "Just, because it's on CPAN, doesn't mean it's made of Gold" , idea - but what is? and what isn't? Sometimes it's hard to distinguish.

I disagree with the importance of Pure Perl fallbacks, they are nice to have in some cases, but really, just about every *nix system comes with a C compiler and with the existence of things like Strawberry Perl the Windows platform is becoming less of an issue. IMO, effort is better spent making it easier to compile and install C based extensions then it is spent re-writing these extension in a slower Pure Perl version.

Still, the ecological nitch is that the users don't know how to use CPAN, even if they have it available. I tear out my own hair sometimes when CPAN gets unyieldy. That's not something my users are even going to attempt.

If you are looking to distribute your code easily without your users needing to install 1/2 of CPAN, then you might want to look into PAR, which is about as close to PHP-ease-of-installation as Perl gets these days.

If I could find an easy enough to use tutorial on how to do exactly that, I would - but the docs on CPAN still read as if I know what the heck I'm already doing. Perl is only user-friendly to Perl hackers, it seems. It's why people *use* php.

And a app packaged in PAR needs PAR to work! It's a chicken 'n egg thing again.

 

-justin simoni
skazat me


Comment on Re^2: Pure Perl Modules, XS Modules, what's the current trends?
Re^3: Pure Perl Modules, XS Modules, what's the current trends?
by stvn (Monsignor) on Dec 20, 2007 at 21:45 UTC
    It is hard to distinguish between Production Ready and not, without signifiers, like version numbers that are above, "1", or something like that. There's always the "Just, because it's on CPAN, doesn't mean it's made of Gold" , idea - but what is? and what isn't? Sometimes it's hard to distinguish.

    But a version 1.0 or above is no more reliable an indicator, I have seen lots of lumps of crap wrapped up in a bow with a big 1.0 on it and uploaded to CPAN. In the end you have to do things like; 1) ask the community 2) look for indicators like the ones I mentioned in my post (resolved bugs, nicely updated docs, etc) and finally 3) read the code and make your own judgement. In the end, it is open source, so you can always patch it and send the fix to the author, or just fork the whole module and maintain your own version.

    Still, the ecological nitch is that the users don't know how to use CPAN, even if they have it available. I tear out my own hair sometimes when CPAN gets unyieldy. That's not something my users are even going to attempt.

    But how is a Pure Perl version of Module::X going to make that any easier? I have had hard times installing Pure Perl modules too, it is not just C/XS based modules that cause issues.

    If I could find an easy enough to use tutorial on how to do exactly that, I would - but the docs on CPAN still read as if I know what the heck I'm already doing. Perl is only user-friendly to Perl hackers, it seems. It's why people *use* php.

    The PAR Tutorial is pretty good actually, and anything you don't understand you can just ask here or on IRC and I am sure you can get people to help you.

    And a app packaged in PAR needs PAR to work! It's a chicken 'n egg thing again.

    This is not actually true, you can tell PAR to package it all into a self contained file which only depends on itself. Look in the PAR Tutorial it specifically says "Requires only core Perl to run on the target machine".

    -stvn
      I'll try out PAR when I have enough time to give it a good grok. It may not be the best fit for this project, but it would be an interesting thing to have in the toolbox.

      But how is a Pure Perl version of Module::X going to make that any easier?

      The Pure Perl versions have an advantage, since you can just bundle them up in a download with, say, (in my case) a webapp that requires it. I can't really do that with an XS module.

      Of course now, since I'm not using CPAN, all the package goodness is out the window. I'm hoping to move this particular app into a mode where you can install it via `make; make test; make install` if you want (using Module::Install) and if you don't know how to do that, you can just download a prepackaged deal. Currently, you're only choice *is* the prepackaged deal. Popular with end-users, not so elegant when looked at by Perl Hackers. What to do?

       

      -justin simoni
      skazat me

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://658271]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (15)
As of 2014-04-18 21:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (472 votes), past polls