Guay_Jean-Sébastien <[EMAIL PROTECTED]> wrote: > These answers are of course my own experience, but may be significant to > understand the bigger picture. I reorder your points a bit in my reply :-)
No problem :) > > So, why is it that most of the solutions represented > > in this group tend to point to a CPAN module when > > the code for it isn't that hard (usually) to write? > > a) It may not be hard to write, but it may have implications you don't see > at first. For example, something dealing with dates. Does it need to deal > with leap years? Does it need to deal with localized date formats? etc. etc. > When you use a module like Date::Calc, the writer has thought of this, has > written it when only thinking of what the module needs to do and do well, > and has normally well tested each part of the module. I would definitely agree with you on Date::Calc. It's saved me more than once :) I don't know if this [specific] module is "standard" or not, but it was already installed on the servers, so I am guessing it is. I have NO problem with using 'standard' modules. Just like the C library -- it's just part of the industry standard. > b) As new need arises in your program, using a module gives you access to > other functionality which you would have to (again) write yourself if you > were not unsing a module. But would you agree, that at least in some cases, it is "almost" as hard to use and understand a CPAN module then to write your own? Some of the documentation out there isn't the greatest :) [...] > The other point is that when you're working on increasingly large projects, > you reach a point where the amount of work for a given project would be too > large (in time/money/etc) to be practical. That's when using modules for the > general "low-level" parts is really useful. This is true, and if it is a "tried and tested" module (like Date::Calc or Net::FTP), I would totally agree with you. But I've used some modules from CPAN just as this group suggest <grin> just to find out it had a bug in it. When trying to contact the originator, the email address was defunct. So (being honest here) it makes me a little bit paranoid to use a module out there just because it is on CPAN. If it was one I've seen listed here many times, I would tend to trust that particular one. But face it, there are hundreds if not thousands of modules found in CPAN. And not all of them were written by the perl gurus :) > Using modules can, in some > cases, prevent you from thinking of a project as code, and more as "how do I > solve this problem". That's why in large projects, most people will want to > make modules of their own for some parts of a problem that can be > generalized (if an existing module doesn't already exist). It factors out > some parts of the problem (once the module is well tested), and brings you > to a higher level of abstraction. For larger projects requiring complex algorithms, I wouldn't hesitate to find something in CPAN. > > But if any of you are like me, you don't have > > access to install modules that run in a production > > environment. > > It's pretty easy to download a batch of modules onto one machine, and make a > script to install them all onto multiple machines. Even if you can't do it > yourself (because there's an evil SysAdmin who won't give you access) you > can give him a package, containing the module tar.gz files and the script, > and it won't be hard for him to install them. Most SysAdmins have developed > a way of running a given command on the whole farm of servers... (chell > scripts, normally) The admins here are a bit strange. They see no problem with me adding application code to do this or that, but they DO have a problem with code being added to "/appl/site/perl5.8/lib" [or whatever] since they (naively) feel that it would adversely affect the perl executable itself and/or other application developers using 'perl'. Yet I can install my own bug- ridden code code and bring the server to its knees. Go figure :) > And if the SysAdmin still doesn't want to, go a bit higher, stating the fact > that installing these modules will reduce your work load (increase your > productivity), make your programs require less testing, etc. Managers react > well to things that translate directly to dollar signs, and you're actually > telling him the truth to boot! You're absolutely right, and that is perhaps where *I* need to make my case. Another responder to this question also suggested to at least evaluate the code from the module so as not to completely re-invent the wheen (good suggestion, BTW). > Hope this helps, Yes it does, thanks. -Jeff __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
