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.
- I know that the parser optimises away constants that
are concatenated together. Thus, $s="my".' friends';
inside a loop is no slower than $s='my friends';
- I know that if (0) {}; poofs away in the
parser as well.
- I know that order of execution isn't guaranteed in a
math expression. Thus $x = $y++/--$y; is evil since
you have no idea which side of the '/' perl will do first.
- I know most OSes only allow a program about 256 open
handles. So after the three on unix that you start with
already opened, you hit a nasty wall after opening 127 pipes
to yourself or 254 files for reading and writing at once.
- We now know that 'no' leaks memory and that it seems
worse in 5.6.0
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) |
(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";
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. |
|
|
