I think this is a dangerous idea. I recognize that there is value in learning how things work, but I believe that value lies in learning how to trust that which is already known to work.

Consider, for example, basic math classes. In geometry class, you're taught how to prove basic theorems, not because there is doubt about the theorem's validity, but because there is a specific process to learn and a set of known theorems that must be trusted to get to the good stuff. I found this frustrating at the time because I never liked having to repeat someone else's work. When I got into algebra, I started to understand geometry a little better. Trig helped me understand algebra more. The same thing happened in my Calculus classes, each built upon the foundations learned in the previous classes.

However, that was school. Since programming most often occurs in a business environment, the goals change. Yes, you're learning new skills, but you're also trying to produce an end result for some material or competitive gain. Because it's a competitive arena, results are mandatory for success. You don't always have the luxury, time, or resources to verify (or rewrite) that which is already known to work.

To that end, you need to have a certain amount of faith in the tools available to you. Certain modules, like CGI, are known to work well. I don't believe it makes sense to re-invent them. Yes, it's nice to master the idiosyncrasies of the HTTP protocol, however, is it not more productive to simply trust that Lincoln Stein understands that process very well and focus on using the values given to you by the param() method?

Now, not every module is as well-written as CGI. Not every module author is as skilled as Lincoln Stein or Gisle Aas. When dealing with lesser-known modules (or authors), it makes sense to review the source for dangerous practices. It makes sense to study the module's behavior, effects, and performance in the conditions you're working with. If the module appears to operate successfully, then it makes sense to trust it a little more.

Unlike other languages and development environments, Perl makes it easy to gain this trust because you can get to the source for free. Sure, you have to invest some time in actually reading it, but at least you haven't comitted untold dollars to a vendor based on vague promises. You haven't had to sign a pact with the Dark One for the privilege of viewing (but not touching) source.

I don't believe it makes sense to reinvent the wheel (or a module) unless you cannot find one you can trust. (Before doing that, however, I would caution you to verify your conclusions by posting a message out here, just in case someone else has already been down that path.)

Bottom line: at some point, you're going to have to make an decision about your project and the tools you'll use to finish it. If you're not willing to trust the work of others, then you've greatly increased the amount of work you need to do for others to trust your work. And that takes a lot more time.

On the other hand, if you're willing to trust someone else's work, then you've just saved yourself a lot of time that can then be invested in solving the actual problem at hand.

So, yes. There are times when it may be instructive to re-invent certain things for educational purposes, however, it may be more cost effective for you to focus your limited production time on solving new problems. Definitely take the time to verify that your trust is well-placed, however, don't cripple your project at the start by reinventing things that already work.

--f