http://qs321.pair.com?node_id=967904


in reply to Top 11 (GOOD) reasons not to use someone else's Modules

Hello miketosh. As a dabbler in Perl, there are only a few things that I can touch on here, and I may repeat what has been said by the others.

  1. Learning: How are you learning Perl by ignoring one of the best aspects of the language? Modularization is probably the best parts of Perl. Reusable code is almost the back bone of Perl. I would be totally fed up with Perl by now if I could not reuse the code I wrote or use code written by others who know more about Perl than I do. Also, not using the modules written by others keeps you from learning too. Learning to use other people's code could be a major headache, but it could teach you a thing or two about Perl that you did not already consider.
  2. Perfection: If you have been writing Perl for any length of time, you have probably come across the concept of "there is more than one way to do it" also known as TIMTOWDI. As long as there are many paths to the same result you will never find perfection in your code. I am constantly tweaking everything I write, even those programs that I wrote with the help of others' modules. Perfection is not entirely possible as long as TIMTOWDI is around.
  3. Purpose: Just because a module does not do exactly what you want does not mean that you can not find a way to bend it to your current task at hand. One of my favorite modules of all of the modules I have found is Lingua::EN::Inflect. It may not do everything that I want it to do, however, I take what it can do, use a little imagination, and manage to get the result I want. The purpose of modules is to make things easier for you as long as you have the imagination to make them work for you.
  4. Appearance: If Perl is already installed where you are working, then guess what, you already have modules at your disposal that install with it. Take a look at the list of core modules. Since they are already there, go ahead and use them.
  5. Portability: I am confident that there is a way to make your code portable without you having to redo the work of someone else. All you have to do is go to the search box above and use it.
  6. CPAN access: I can not speak to this issue, since it has never really been one for me.
  7. Compiling: See CPAN access.
  8. Complexity: Never ever say that there is such a thing as a one time script. I said that once and then a few days later I bit my tongue. No matter how small or large, everything you write has the possibility of creeping back into your life when you least expect it to do so. You might not use the exact same code, but it will be close enough where only a few tweaks can make it into a useful reusable subroutine nestled in a module.
  9. Size: See CPAN access.
  10. Licensing: See CPAN accesss.
  11. Job: You are probably paid for your time to write the code to do the job that they want to get done. I think that you are taking advantage of your clients to milk more money out of them by not using modules. If I need to print out a report for a client that wants dates in a certain format, I am not about to waste their or my time rewriting what Date::Calc or DateTime can do faster than I can write the copy of the code for it. Think more about the dead line they have set. Modules will help you meet those dead lines with no problems. I do not know what I would do without List::Util's min and max subroutines. There is also one of my life savers, Data::Dumper that I would not feel like attempting a rewrite.

I have been told here plenty of times to not rewrite the wheel. That is what it sounds like you are doing here. Learning to use modules in hostile environments that you are describing is probably the best thing that you can do, however, do not do it on your clients' time and dime.

Have a cookie and a very nice day!
Lady Aleena