Exploring is great, I love learning how to do new things, and I love to understand how things work. I have even been known to write yet-another-XML-processing module.

The problem with people trying to re-invent CGI.pm is that they usually don't realize how far they are from something that works beyond the simple tests they do before putting their scripts up on their web site, and most of all they don't realize how dangerous most of their scripts are. By not using CGI.pm they are endangering both their company and their jobs.

When you see a 3-year old playing with a gun the first thing you do is take the gun off their hands. Then you can explain why it was not such a good idea. Or other people might just yell at the kid. But the main point is just to take the darn device off his/her hands. It's just the same here. Don't let them play with something dangerous and that they don't understand.

BTW I also love to learn how to use existing modules in creative ways. If a module does not work as advertized or just if it looks interesting then I go under the hood and look at the code. Frankly I find it way more interesting than making yet another attempt at parsing a query string or an email address.

And when I decide to reinvent the wheel at least I do it in a domain I am familiar with, with good reasons and knowing what problems I will face and how others have solved it. Don't confuse Hubris with Blindness, or, as Larry would describe it, False Impatience or False Laziness ("I don't have enough time or energy to learn a new module, I'll quickly hack somethnig that works for me").

The key is knowing what to re-invent and when. And most people seem to err on the side of too much re-inventing, often out of pure ignorance. Why not improve an existing (working) module instead of re-writing poorly?

When I first started Perl in July last year (For a summer internship) I was fairly unaware of CPAN and wrote a few date manipulation routines for a smallish script I was working on. The guy who worked next to me, a seriously talented (double underline in bold) programmer, took one look at the code, pointed out a no-brainer in one of my assumptions and then commented that although it was very pretty, why didn't I use CPAN?

Uh, what's CPAN?

CPAN opened up an entirely new vista to me. In some ways this has made me guilty of mild 'cargo cult' programming as I don't really understand the complete inner workings of, say, CGI.pm, but it does allow me to build small applications very rapidly indeed and deals with several issues I otherwise wouldn't have been aware of.

The real point of this mail is that sometimes it is useful to write a quick 'n' nasty routine to do something that a module would do better: "Oh, your PC doesn't have Date::Manip installed and your network connection is down, uhmm okay. Epoch to Human readable shouldn't be too hard." One of the nice or nasty, depending on your point of view, things is that in Perl it is very easy to re-invent the wheel: It does nice things for you and makes the tricky very simple. Once, when I was about 12, I spent an afternoon writing a BASIC program to interconvert binary, octal, decimal and hexadecimal - this would probably take me about 5 minutes in Perl (I've no idea how to do it because I've never needed to, but a quick search here,in the blue camel and on CPAN would give me the answer doublequick.)

Perl is a natural language for quick 'n' dirty applications such as reformatting files, global search 'n' replaces and cronjob run data logging. It also does bigger things nicely, too. I like Perl.

I'm also having a go at reinventing the wheel: I'm going to try and build a Perl-only implementation of Blowfish when I have the time. I know that this has been done before (Hint, look at CPAN ;-) but I'm adding it to my list of things to do, including looking at Artemis, I haven't forgotten ichimunki I'm just busy with exams!

Elgon