This is a classic "buy versus build" decision.
Whether or not to use a third-party CPAN module depends on your environment and on the quality and trust you place in the third party code. Notice that this is broader than just Perl and CPAN. In our case at work, for example, we commit to maintaining a large amount of code by many different programmers over many years that runs on many different platforms and is sold to thousands of customers. Accordingly, we consider any third-party dependency very carefully. Does the license allow us to freely redistribute it? What if there is a bug in the third-party code? How quickly can we troubleshoot it (often remotely at a customer site) and fix it? If you don't understand the third-party code or don't have good third-party support for the third-party code, you will be in trouble. That is a significantly different environment to someone writing Linux-only software for their PhD thesis. Or a company that writes single platform inhouse application software.
You should also consider how much the third party software gives you, how hard is it to write it yourself. To give a specific example, we don't use File::Slurp because we don't feel the third party dependency is worth what the module provides; after all, it's easy to write your own file slurper. OTOH, we do use XML::Parser because it's a significant effort to write your own XML parser. To give another example, we wrote our own C++ unit test framework (because that is a simple job and we didn't want a third-party multi-platform dependency) while we did not write our own C++ compiler (which is a lot more effort). Unlike C++, there is a rock-solid de facto standard testing framework for Perl (Test::More) so we used that and did not roll our own.
In reply to Re: w/Modules and w/o Modules
by eyepopslikeamosquito
in thread w/Modules and w/o Modules
by Jeri
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |