in reply to The benefits of pathological behaviour

I agree completely, and the same goes for `reinventing the wheel'. The point is that while we should be understanding of those who are doing things the Wrong Way (or an apparently Needlessly Different Way) for learning purposes, such things have no place in production code. That should be the message; not `don't even think about doing that', but `that's a Bad Thing; play with it if you like, but don't use it for anything serious.'

It's all very well knowing what the Right Way is, but no lesson takes hold like the one that was learned from experience.

And by the same token, there is an argument for people rolling their own CGI code, say, as long as they don't seriously plan on allowing it into a live cgi-bin. True, they'll probably be reinventing the wheel. But maybe they'll invent the sledge instead. Just because CGI.pm does a bloody good job doesn't negate the possibility of there being a better way to solve the same problem or, more likely, a better way of implementing one small part of its functionality.

Such `playing' will probably never warrant an entire replacement for the established module, but it might result in a suggestion or two for the module's author, and will almost certainly result in your having a greater understanding of why the module is written as it is and a better understanding of programming in general.

Having said that, nine times out of ten people asking `silly' questions really are planning to use that method in production, and the `eep! Don't do that!' response is usually valid. But if it isn't clear why they're doing it, an explanation of why it behaves that way and why it's wrong would be more appropriate.

Writing code a certain way because `everyone says it's right' can, on occasion, amount to cargo cult programming.
--
Tom Waddington
  • Comment on Re: The benefits of pathological behaviour

Replies are listed 'Best First'.
"Re-inventing the wheel"
by DrDubious DDQ (Initiate) on Feb 01, 2001 at 03:12 UTC

    Your comments have restored my faith in humanity...in this context at least. :-)

    A brief bit of background - My ISP had PHP available on the webserver whence personal homepages were served. Discovering this, I recently got off of my lazy butt and started rebuilding my otherwise ancient, unmaintained, amateurish, and downright embarrassing personal website, using my recently aquired PHP skills. Last week, they decided to upgrade the webserver. They left out PHP, thinking nobody was using it.

    All the scripts on my site now useless (except for a place where people can go to laugh at my PHP code when it pops up on the screen instead of the results), I decided that until they get PHP back up (I was able to contact the admin, and was told they'd see about putting it back online at the next maintenance, sometime in February), I might as well take the opportunity to learn PERL cgi.

    Here's the problem - I have only web and FTP access to the webserver in question, so I can't do any software installation myself. I've still not (as of this moment) been able to find out if cgi is even enable-able on this server. If I finally manage to find out, there may or may not be CGI.pm on it, and if not, I may or may not be able to get them to install it (and even if I can, it may take WEEKS at this rate). So...I signed on here and started looking for "what are some ways of directly pulling passed CGI parameters if I can't use CGI.pm?". The examples I saw all had the same sort of comments. "Don't reinvent the wheel. Use CGI.pm". "Noooooooo! Say no to cargo-cult programming! Use CGI.pm!" (etc.) It was, to say the least, disheartening.

    Personally, I think reinventing the wheel is one of the most effective ways to learn about wheels that there is, at least for me, so thanks for some words defending it.

    Of course, I have no idea if anyone will even see this reply, as the message I'm replying to seems to be almost a year old, but what the heck.

    (Disclaimer - these are the words of a groveling newbie. I probably don't know what I'm talking about.)

[reply]
      You may possibly be unable to run cgis at all, so I would suggest you make sure of that first. I would probably just ftp a very basic perl script first and see if that can be run, showing if cgi is enabled and if perl is installed. 
      #!/usr/bin/perl 
print "Content-type: text/plain\n\nworking\n";

      [download]

      For the other part of your post, I would say that yes, re-inventing wheels is something to try, but don't expect to actually use that code for anything you care about.

      If you search all those posts about using CGI.pm, you can find links such as the list here. I suggest you read all of those related to cgi, including the full specs and you continue to search for more documents.

      The CGI.pm module has support for these features missing in most parsers written:

      • Multiple parameters with same name ?foo=hi&foo=blah
      • File uploads with many files
      • DOS attacks through long data uploads and the like
      • A consistent interface
      • Modularity
      • Updateability (it's constantly scrutanized and updated for exploits in its code and cgi security in general)
      • Scalability
      And probably another hundred more that I can't think of but are needed if you want a fully safe and reliable cgi engine other than CGI.pm.
[reply]
[d/l]
[select]

In Section Meditations