Quite honestly, I don't think that node was a valid question, but a troll. It had all the keywords designed to irritate (CGI.pm and re-invent...most people who re-invent CGI.pm do so unwittingly), and it didn't have a good reason for the re-invention to back it up. Update: I just read the entire node not just the root message, and it looks as if it was a troll.

So in this case, I think the advice was on target. There are many ways to do things, but if you don't even understand the task well enough to know how to start without help, then you will probably shoot yourself in the foot. Advising against self-mutilation is not a bad practice.

I have what I hope is a good instinct about whether this level of understanding has been accomplished, mostly based on the noises I make when I do it myself. {grin}

If someone tells me "I don't want to use CGI.pm, it's too _blank_", I say "pshaw! off with you, troll!"

If someone tells me "I want to rewrite CGI.pm this weekend, as an exercise in hubris", I say "do you know everything it does, and do you have the four months that it will take to do that?"

If someone tells me "I want to fix the problem where CGI.pm does X instead of Y contrary to spec Z, and I'll work with Lincoln to incorporate it into version N+1", I say "go for it!".

-- Randal L. Schwartz, Perl hacker

Sorry for chipping in on an older thread.

merlyn, very often the only way that you can appreciate an existing module is by trying to reinvent it yourself. You get smacked by the same problems as the module author, and you learn to appreciate his/her response to those problems (or not as the case may be).

A case in point was yet another getopt module that I wrote because none of the existing ones provided quite all the features I wanted (notably the use of argument files). That worked fine until I needed to start having to tweak it for features that existed in the standard modules. I have now gone back to using getopt::long, and adding my stuff by reprocessing @ARGV before extracting the options.

The point is, that I now understand Johan's module and use it more effectively than I would have done otherwise.

I feel pretty ambiguous about this question. On the one hand I'm in favour of rolling my own stuff in personal or low impact scripts. Sure it takes more time, but I'm learning... On the other hand, when it gets to production code, I have to agree with you. The problem isn't so much reinventing stuff (with all the mistakes to be made again) as having to maintain it afterwards.

And I suppose that's where the problem really lies. It's our responsibility to <quote>The Community</quote> to make things as easy for them as possible... by providing guaranteed robust, maintainable code at low cost. But there's another responsibility to explore, understand and innovate in order to extend the robust code base. And in order to do that you need to feel free to step outside the tried'n'true and play by your own rules for a while.

I agree with you. This isn't a black-and-white issue for me (see (tye)Re2: 'Tailing' a File?). However, processing forms w/o CGI.pm is almost always a mistake and, in this case, I don't think trying to reinvent CGI.pm is a good idea.

Now some serious rewriting of how CGI.pm generates HTML, sure, that would be worthwhile. (: Seriously, though, feel free to rewrite all of the CGI.pm after you thuroughly understand the current CGI.pm. I think someone already did that, in fact, with CGI3.pm (whose exact state I think we are still unsure of).

A few years back, I did some fairly extensive perl programming on the Mac. At the time, it was a good bet that any module that required compiliation (XS) or depended on a module requiring compilation wasn't going to work. I spent the better part of a weekend writting date calculation routines because I couldn't use Date::Calc and Date::Manip was overkill for the project I was working on. Things are much better on the Mac side these days, but I can see this happening again. I just got a Psion Revo and installed the EPOC port of perl 5.6 on it. Not only is it unlikely that anything from CPAN will run in this environment, but some of the standard modules will not run on the Revo. If I do anything serious with it, I see quite a bit of wheel reinvention in my future. The point here is that there may be a good reason that someone would try to rewrite tested and highly regarded code. We should probably try to clarify motive before passing judgement.

While I don't feel comfortable enough in my robes to really be active in the monastery, I do have some general rules I follow when voting or commenting on a node:

• Check the poster's home node before voting. If a person is new to the site or is at a fairly low level (<4), I /msg the user rather than downvote them.
• Ask for clarification either in responses or in the chatbox if the reason why a question was asked is unclear.
• Ignore bad postings by the Anonymous Monk. If these postings make it to the Worst Nodes list, then we are likely to see more trolls. The original poster will not see the rep of their node, so downvotes are not effective in shaping the poster's behavior. Also, the Anonymous Monk does not have access to the chatbox, so we can't easily clarify the poster's intent.

TIMTOWTDI is one of the things that makes perl so compelling for me. The atmosphere of perlmonks keeps me checking the site several times a day. Thanks, deprecated, for bringing this up I would hate to see perlmonks pick up the unfriendly (although justified) feeling of comp.lang.perl.misc.

----
Coyote

This is not as unreasonable as it looks, and here are a few rules of thumb.

First of all if the wheel is (like CGI) something that involves security, I am against anyone reinventing it without having very good reason. (Auditing the code and finding it is insecure and not fixable is a good reason.) In general with this kind of problem, even if reinvention is necessary, I don't want to see it reinvented by the wrong person. If you have to ask how to reinvent CGI, you shouldn't be doing it. Similarly if you don't know enough to know why you shouldn't be inventing your own encryption algorithms then relying on them, you certainly don't know enough to attempt the task.

Secondly, what is the wheel going to be used for? There are many wheels that are instructive to build. By all means build them in your spare time. But if you need to produce something for production, generally it is better to go with the existing wheel.

Thirdly there is the harder question of what I think about the current wheel. That comes down to many questions. For instance I may have heard things about the author (eg Matt Wright) that indicate that I don't really want to bother evaluating their wheels. Or I may know something about the module (eg the extremely poor performance of Math::BigInt due to constant string-array conversions) that makes me not want to use it. Or I may look at the API and decide that it is not one I want to code against for a variety of reasons. This involves a subtle combination of knowledge, intuition, and experience. (Also some prejudices...)

And last but not least, there are wheels that are just fine to reinvent. For instance I was asked why in Continued Fractions I did my own rounding rather than use Math::Round. Well the answer was that the use of sprintf for rounding is a wheel I was familiar with, I had never heard of Math::Round, and even after reading it I didn't see any rounding function there that matched my need. I reinvented that wheel, and would do the same again without hesitation...

Yes, we're all a community, and yes, it is our responsibility to further the core values of perl. One of which is TIMTOWTDI. If you don't believe that idea belongs in perl, start to change it. I just dont think we should be discouraging people as boldy as we did

It is so nice to see concern as stated in your post, in a coding community. I've had to deal with several non-perl newsgroups/lists of late. This concern for the 'values' of the code is what IMHO makes Perl, Perl.

I don't care if Perl can't make everything a nail, or how often I hit my fingers trying anyway. Perl's very structure enforces TIMTOWTDI and thereby gives keys to the doors of creativity that other languages can't touch. It ensure's accessibility to even the neuroticly creative, and you just know they'll ALLWAYS Find another way to do it.

I think that though Perl is in it's adolesence, it has solidified it's flexible personality in what it has already been achieved. Just because someone (even the most venerable of monks) gives a suggestion, the suggestion can never take away Perl's many aspects of TIMTOWTDI.

Jonathan Moran

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?

Yarrg.

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

But we should not let this become blind fervour, unquestioningly accepting that there is only one way to do something. All communities need a good devil's advocate - even if only to convince us we are still doing the right thing.