FLAME! FLAME! ;-)...
> Question for this group. And please don't flame me for asking this. > > Often times one writes in, asking how to do something fairly trivial, > such as a date conversion from a non-standard format, or doing something > else not require too much overhead. The problem, is to me, context, if doing date conversion is "fairly trivial" then why are there so many modules involving it, and why are they so complex? There were at least two issues involved in the post that I assume sparked your questions, 1 the ordering of the parts, some parts of the world use a mm/dd while others use dd/mm, while I prefer yyyy-mm-dd the people at the bank think I am weird when I date my checks that way, the other being that the year was stored in two digits instead of 4. So often a response is to use a module because a responder has "been down that path before, you know where it leads..." and doesn't want that person to have to make the same mistakes again. Better examples include CGI header parsing, and e-mail parsing (don't try this at home boys and girls!) or e-mail sending. While they seem simple enough, they are actually incredibly complex beasts because they have "matured" (read: so many people (and large corporations that start with M) have added so much crud to the original specs that standards no longer hold and you have to be insane to attmept to tackle all possibilities yourself). So while the OP may see them as simple, and in some cases the context can be narrowed down to such a fine scope that a module may be over kill, in general this is not known or stated apriori, so the responder takes them as their normal complex selves. Then there is that whole re-invent the wheel thing ;-)... When asked for advice, nine times > out of ten, the responded will refer the originator to such-and-such > module at CPAN to download and install. Many of them also come with more recent Perl installs. Prior to 5.6 you didn't get many of the modules commonly noted, after that and depending on your distribution you do get them with the base install (thank god). I'm all for not re-inventing > the wheel -- don't get me wrong. But if any of you are like me, you > don't have access to install modules that run in a production environment. Right but is this a fault of the responders quoting that a module should be used, or yours? (Don't take that negatively). If we are talking about a true production environment then surely you have version control systems, release management tools, automated processes for pushing software updates into service, etc? Part of running a "true Perl app" aka not a bunch of 4 line scripts put in root's cron, is having the ability to install CPAN modules and keep a local repository. I would insist that what you really have isn't a production enviroment. Also as I pointed out to Dan, this is an open source world where you can check for yourself, so often a module may be mentioned as a place to find an implementation rather than actually sucking it in and using it in whole (although that meaning may be lost on beginners, especially from winders, just pop the hood baby!)... > In my case, we have a couple of test servers and several hundred satellite > servers that run 'production code'. So, installing a module is out-of- > the-question. In my case, I am basically "stuck" with the perl [5.8] > default libraries and modules. > How do you distribute your code to the satellite servers? Couldn't you do the same with the CPAN modules? Granted we are running a single server production environment, but we install the modules to Q/A using CPAN then copy the full repository to production rather than re-installing. Naturally this relies on Q/A matching Production, but then I wouldn't want to work where they don't! > 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? I'm not sure if using modules is a matter of "convenience" > or "necessity". While the solutions shown here will most often work, > they aren't practical for Joe Programmer working in the corporate world > (don't flame me! LOL) who doesn't have access to install as root or install > on many many servers. > I think the simplicity of the problems mentioned here cause this overall effect, currently the application I am working on is 15K+ lines (not a lot) but if you factor in the thousands of lines of code I *didn't* have to write by using a framework such as POE, logging system Log::Log4perl, incredibly complex mail handling by Mail::Box, and the GPG encryption system then all of a sudden the number of lines has grown astronomically... and I (well my employer) got all of those without paying a cent! What a world! > My point being, it might be helpful to provide a solution such as > > See xxx::yyy at CPAN or my solution below > It might, but in many cases "my solution below" would be completely inappropriate and would just further bad habits of trying to "parse dates with split" or "sending e-mail by using a piped open to sendmail", or "parsing filenames in a cross platform manner" or "system'ing out to <insert command line tool here>"... > I tend to believe that most people part this list distribution do coding > for a living, while others just tinker with it on the side or are > students. > > I suppose one way to point to a CPAN module and not have to install > as root would be to install the module in the application library path. > Wrangling @INC and getting that path just right is sometimes and art but will definitely help any coder in the long run. drieux has some excellent rants on this in his normal location.... > Thoughts? > > Worthy questions I think, but you have to convince me with more than "I have to copy some files to a hundred servers" before you can pry CPAN from my cold hands.... ;-)... http://danconia.org -- Boycott the Sugar Bowl! You couldn't pay me to watch that game. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
