Occasionally at $WORK pragmatism dictates that we are forced to use something which we despise. The something might be a module, a language, an application, an O/S or whatever. Finding some additional tool or technique which renders use of the something slightly more bearable can be a help.
| [reply] [Watch: Dir/Any] |
Quite right!
A couple of things;
I recognize that while I, don't care for it (CGI). I also recognize that many, if not most others do like to use it.
My reasons for not choosing CGI, as a rule, are that it abstracts so many simple things, that are nearly, if not just as easy to do without it. Saving a bit of overhead in the process. Abstraction, IMHO, also has a nasty side effect. In that if you don't do something for long enough, you'll forget how it's done -- Use it, or loose it, as it were. Of course this simply isn't practical in some/many cases. But if one remains mindful of it. I think a healthy balance is maintained.
My reason(s) for acknowledging the CGI::Carp::DebugScreen Module, is that, as noted earlier, I know that others are inclined to use it (CGI), and felt this might be for them. Where I'm concerned, I felt this had some interesting, potentially valuable use cases for emitting useful information that would otherwise require me to cobble up routines/subs to acquire. Given that this already came with prepackaged templates. I thought it a plus. I was also able to justify it's usage, in spite of my general feelings for CGI, because it was so small, and wouldn't be something I'd be using on a daily basis -- at least not where production is concerned (released code) -- see; not shipped with.
Thanks for calling me on this. :)
Best wishes.
--Chris
#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;
| [reply] [Watch: Dir/Any] |