Re: Simplicity vs. Doing It Right

[BrowserUk]

++dws, and thankyou for saying it. This is a similar point to the one I was trying to make in Being a heretic and going against the party line..

It's not that I have anything using modules, nor that I don't appreciate the long term benefits of the tested-ness (sorry for that but I simply couldn't think of a better way of putting it) that comes from using the proven solutions and would probably do so in most cases for production work or anything that I had to revisit more than once.

However, even assuming that you know the right module to use rather than needing to go through a long list of possibles to determine which one is right, it can still be a pain.

As an example, in this post, I set out to 'do it the right way' and use CGI.pm. After nearly 2 hours of trying, I gave up and hand-rolled my html output because I could not work out the right combination of maps, anonymous arrays and CGI functions to produce the output I wanted. I came close a couple of times, but as soon as I tried to add the final peice to the puzzle it just crashed around my ears.

So I opted for a loop and some print statements and it worked first time (honest!) and took less than 5 minutes. When I chose to add an extra (left-hand) column to my table, it was obvious exactly where and how to do it. I gave up completely on the idea when was trying to using CGI.pm.

I admit, by the time I got to writing the homebrew version, I had the benefit of a lot of thinking that I had aquired trying to do the CGI/maps/distributive function method. Even so, a 24:1 ratio of time taken to achieve a solution (actually higher as I never did) would pay for a lot of maintainence were that ever necessary.

I guess you pays your money and makes your choice, but if I am paying the bills, I will opt for the 'simple solution' over the 'right way' every time.

---

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!

[jeffa]

You must be referring to the code over at Re: Re: Hex color degrader. I decided to take the 'Pepsi Challenge'™, and - not to best you - i thought it would be benificial for the community to post a very similar solution that used CGI.pm's methods: (refer to said link for orginal code)

print start_table, Tr(td(' '), th[@colors]);

for my $scale ( -5 .. +5 ) {
   print Tr(td($scale/10)),
      Tr( 
         map { td{bgcolor=>'#'.$_},$_ } 
         map { Dlighken($_, $scale/10) } @colors
      )
   ;
}

print end_table;

Thanks to your existing code, it only took me about 5 minutes or so to port - however, when one considers how much total time that i have spent learning how to massage CGI.pm, i feel that your argument here bears even more weight. I liken this to playing a musical instrument - the time one spends practicing different scales, licks, chops, etc. will, in the long run, improve one's improv skills. But, when on the spot ... it's best to stick with what one knows right now.

Cool code, BTW. :)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

[BrowserUk]

In my defense, I was trying to be a little more CGI.pm about it and adopt the 'poetry mode'. With another hour of giggling I finally cracked what I was so close to before.

This produces the same out put as my original above and uses but a single print statement, in deference to all those post I've seen saying "You don't want all them print statements, use CGI.pm" ;^).

Whether this is better or worse than my original or yours I'll leave it to the reader to make their own conclusions.

#! perl -sw
use strict;
use CGI qw/:standard *table/;
use CGI::pretty;

sub Dlighken {
  return sprintf '%02x'x3,
      map{ ($_ *= 1+$_[1]) > 0xff ? 0xff : $_  }
      map hex, unpack 'A2'x3, $_[0];
}

my @colors = qw/800000 808000 008000 008080 000080 808080 c0c0c0/;

print
    table(
        Tr( th(' '), th([@colors]) ),
        map{
            my $scale = $_/10;
            Tr(
                td($_),
                map{
                    td({bgcolor=>"$_"},[$_])
                }
                map{
                    Dlighken($_, $scale)
                } @colors
            )
        }( -5 .. +5 )
    )
;
__END__

---

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!

[Aristotle]

I hardly see a reason to use CGI's HTML generation routines - the output is still hardcoded, so you don't really win a thing over just putting strings in your code. The only possible difference is it automatically produces well formed XHTML. Shrug. If I hardcode my HTML for a small script, I use a heredoc or something. Anything else, I use Template Toolkit II. (Literally everything; I'm starting to use it in command line scripts too.)

If you look around you'll see that there's hardly anything like a consensus that CGI.pm's HTML routines are The Right Way, and in fact some quite highly regarded folks will tell you to first look for another solution.

Just because a module offers some functionality, even if it's a core module, doesn't mean you have to or even should use it. FindBin f.ex is so badly broken I actually find it sort of embarrassing that it's in the core.

Makeshifts last the longest.