Every so often we get a new or elder monk ask a question of the "Hey Doc, it hurts when I do this." nature. Often, the immediate response is "Stop doing that," in accordance with the old old joke.

I would like to encourage you all to put aside your blinders on these questions and look a little closer at what the pathological behavior often winds up teaching us. Today the winner is :eval + no warnings = no memory. I wish I had marked some of the past ones that amused me since they taught me important things.

The issue here is, when you stress something past it's intended limits, you often learn more than what the limit is, you learn why the limit is or that a huge bug exists. =) I've soaked up a lot of interesting data about Perl the language and perl the executable and the systems that perl runs on thanks to the pathological edge-walkers and push-to-the-limit-types.

There are a million of these oddities floating around in any language and many of them are indistinguishable from features. They are the difference between knowing what works and why something broke. Sure we should be suspicious of people doing mad things but the mad people find all the good bugs these days. A few times a year, somebody posts a bit of code to the perl5porters that everyone knows is evil and wrong and sure to break only to discover that no two of them agree on where it breaks. Or worse, that it broke something so unexpected that they all just have to sit back and whistle.

In any case, I'm not asking much, just look a little closer at the weird and wacky. There is more there to learn than you think.

Update: go see one-liner hogs for some serious one-liner pathology. =)

--
$you = new YOU;
honk() if $you->love(perl)

Replies are listed 'Best First'.
(tye)Re: The benefits of pathological behaviour
by tye (Sage) on Jan 30, 2001 at 09:16 UTC

    Actually, I don't think no leaks memory. I think eval (on a string) uses a bit of temporary space and by never moving on to the next statement, that memory is never free()d. That isn't a memory leak.

    Update: Based on new information, I upgrade my guess to a memory leak in "stringy" eval on some versions of Perl on some platforms. (:

    I just tried to reproduce the original problem but I couldn't. So I can't verify that there isn't a real leak. I'll try again later. Update: I don't have a platform handy that exhibits the problem. :(

    But I do agree that we should avoid jumping too quickly to the "Don't do that" reply and that we can often learn interesting things from extreme and even stupid coding. (:

            - tye (but my friends call me "Tye")
[reply]
      On my system, I found that virtually any pragma repetitively eval'd resulted in memory snarfage of biblical proportions. At that point, the benefits of pathological behaviour became clear...
[reply]
Re: The benefits of pathological behaviour
by flay (Pilgrim) on Jan 30, 2001 at 22:14 UTC
    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
[reply]

      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]
Re: The benefits of pathological behaviour
by clemburg (Curate) on Jan 30, 2001 at 16:05 UTC

    extremely, I absolutely agree with you if the "pathological behaviour" is exhibited in an interesting way. "Always pushing the limits" has been an attitude that taught me a lot of interesting things in the past, at least in programming.

    The only provision I would make is: know the difference between pushing the limits and doing your work. And if you discover something by mistake, be free enough to admit it was a mistake.

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

[reply]
Re: The benefits of pathological behaviour
by Maclir (Curate) on Jan 31, 2001 at 07:53 UTC
    Some excellent points raised. We need to open our minds a little more sometimes, and not instantly reply "don't do that, use CGI.pm / HTML::Parse.pm / Insert::Your ::Favourite::Module.pm every time someone asks "how do I do this thing".

    The person may be seeking some deeper understanding of how something works, for many reasons - personal interest, improving their understanding of the subject, or wanting to turn the wheel from a basic round stone object, to a better riding, durable pneumatic tyre.

    On the other hand, they may be beginners not really understanding what they are wanting to do. Our task is to discern what they are wanting, and in either case, to help as much as we can.

[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Meditations