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.
In reply to Re^2: Pure Perl Modules, XS Modules, what's the current trends?
by skazat
in thread Pure Perl Modules, XS Modules, what's the current trends?
by skazat
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |