Basil writes.. >My problem with MODULES is you must also install them everywhere, if >you use one that is outside the default installation. Of course the >PASRE is not in the category with Activeperl.
Two comments: 1/ You have to ship the code that does the task anyway, it's either in your own files because you've written it, or your programs are smaller and you ship the libraries that you use. This is the same as the vast majority of other applications which ship with various types of shared libraries (DLLs in Win32 land). 2/ You actually SAVE shipping volume by using modules because (a) two different apps that utilise the same library share the one body of code and (b) a heap of modules are standard - especially in Activestate's distribution. The converse is that everything you ship contains code that performs the same function. >One also must take the time to understand HOW the module works. I >quickly scanned PARSE when I went to use it and used a tag of <TD> but >that in retrospect seems to have been the wrong tag to use. Maybe had >I used TD instead I would have been happy with the module. A situation >that it would have been nice if the module did what I wanted not what I >said :-) Most modules contain POD that an author has taken a long time to think about and write. Most POD contains a SYNOPSIS with working examples of how to use the module, and a lot of POD contains an EXAMPLES section with more detailed examples. Furthermore, by reading documentation - especially examples - your coding will improve as you see other (and/or more commonly accepted) methods of doing things. I think it's a vital part of being a progressive programmer. I usually spend maybe 60 seconds reading through the documentation of a module, then I'll try stuff in my blah.pl file, if I've understood then I proceed, if I've got it wrong then I return to the doco. It's a learning process that builds upon itself because in Perl modules there are often common idioms running through various modules because experienced Perl people tend to do things the same way. >I also find it annoying, that all modules are NOT run with -w and >strict enforced. Geez, if you gonna make it public and all shouldn't ya >take the time to crush the undefined, and other annoyances? Yeah, I agree with you here (at least as it pertains to 'strict'). I am always wary of modules that haven't used strict, it often indicates an old module that sometimes contains problematic code and in that case I don't use it, but that's fairly rare. >Though I agree, if the module is easy to use. And does what you want, >then by all means use it. But if you only need to write three lines >of code that will get the job done for 99% of the work. Is it worth >hunting for the right module and learning that module to get it done >days later instead of in 10 minutes? It depends. If you're taking days to find and learn how to use a module then you need to review some part of your procedure :) In solving a really complex problem I will often find, download, learn and try out two or three modules before deciding on the one I want. That whole process usually takes about 30 minutes. For simple problems the process is even quicker. The time saving, though isn't in that first experience, the time saving is when you come to write the next piece of code that utilises the same module. You don't have to write anything - you just reuse the module. You've INVESTED some time in learning about a certain module and then you can benefit from that time again and again and again. -- Jason King _______________________________________________ ActivePerl mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
