Hello Jeff, 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 :-)
> 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. 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. There are other reasons, but these are the main ones, and can be distilled to "foresight is not 20/20". Not even close, in most cases (for most people). As a coder, if you have to deal with demands of users, and don't code strictly for yourself, then you can never know what your users will ask next. So the previous point is especially important. 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. 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. > 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) 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! Hope this helps, J-S -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
