Hudson River
Gunnar Hjalmarsson
motivated to consider the use of CGI.pm compulsory in every CGI
script, and I have studied the flood of messages from Hudson in the
light of that.
I'm not impressed by Hudson's way to make his point(s). At the same
time, I just don't understand why the regulars, who so strongly
advocate the use of modules in general and CGI.pm in particular,
provoke such reactions over and over again. It's a mystery to me why
some people here make such a fuss about the fact that some of us
sometimes choose to parse form data using a few lines of own code
instead of using CGI.pm. You are lousy missionaries. ;-)
The advantages in principle with reusing code, and hence using
modules, is obvious to every sensible programmer, both beginners and
'gurus'. But hey, some of you need to relax a bit.
At the time when I was under fire, Randal asked: "Why do you keep
challenging me EVERY TIME I say something to you?" and my reply was:
> I think it has something to do with the way you say it. You *say*
> or *tell* in a way that I sometimes find patronizing. If you want
> to avoid being "challenged", try to *explain* and *convince*
> instead. Unfortunately you are not the only one who occationally
> uses a rather aggressive arguing style, Randal; it rather seems to
> be part of the culture in this group. I don't like that part. It's
> unnecessary. It's provocative to me, so I react.
That reply summarizes quite well what I'm trying to say with this post.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
Randal L. Schwartz
Gunnar> At the time when I was under fire, Randal asked: "Why do you keep
Gunnar> challenging me EVERY TIME I say something to you?" and my reply was:
>> I think it has something to do with the way you say it. You *say*
>> or *tell* in a way that I sometimes find patronizing. If you want
>> to avoid being "challenged", try to *explain* and *convince*
>> instead. Unfortunately you are not the only one who occationally
>> uses a rather aggressive arguing style, Randal; it rather seems to
>> be part of the culture in this group. I don't like that part. It's
>> unnecessary. It's provocative to me, so I react.
Gunnar> That reply summarizes quite well what I'm trying to say with this post.
And this summarizes the positions of the regulars here:
Get real! This is a discussion group, not a helpdesk. You post
something -- we discuss its implications. If the discussion happens
to answer a question you've asked, that's incidental. If you post a
question that implies that you've got a problem finding answers to
trivial questions in the manual, then it is perfectly reasonable for
us to discuss how to do that.
Just to be fair. :)
print "Just another Perl hacker,"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Randal L. Schwartz
Hudson> hey...if you go back to my original post, all I was saying is
Hudson> hey...I think this is a really neat way to do soap over
Hudson> http. I actually wasn't asking for help but sharing what I
Hudson> discovered and wanted to discuss it ;-)
And you got a discussion. Why are you then surprised?
Gunnar Hjalmarsson
>>>>>> "Gunnar" == Gunnar Hjalmarsson <nor...@gunnar.cc>
>>>>>> writes:
> Gunnar> At the time when I was under fire, Randal asked: "Why do
> Gunnar> and my reply was:
<reply snipped>
> Gunnar> That reply summarizes quite well what I'm trying to say
> Gunnar> with this post.
>
> And this summarizes the positions of the regulars here:
>
> Get real! This is a discussion group, not a helpdesk. You post
> something -- we discuss its implications. If the discussion
> happens to answer a question you've asked, that's incidental. If
> you post a question that implies that you've got a problem finding
> answers to trivial questions in the manual, then it is perfectly
> reasonable for us to discuss how to do that.
I agree on that. During the months I have been active here, I have
learned, not just to 'endure', but also to appreciate the phenomenon
you just described. Actually, those 'unexpected discussions' make this
group much more interesting than else would have been the case.
What I don't like is the attempts occationally to brutally enforce
certain opinions. Talking for me, that tactic just have the reverse
effect. Not to mention the floods of non-technical messages it causes,
of course...
This is a great discussion group. One moment's reflection once in a
while, before clicking the send button, might make it even better.
> Just to be fair. :)
Right. No problem. ;-)
Tintin
"Gunnar Hjalmarsson" <nor...@gunnar.cc> wrote in message
news:bhl0al$dm3u$1...@ID-184292.news.uni-berlin.de...
> I'm not impressed by Hudson's way to make his point(s). At the same
> time, I just don't understand why the regulars, who so strongly
> advocate the use of modules in general and CGI.pm in particular,
> provoke such reactions over and over again. It's a mystery to me why
> some people here make such a fuss about the fact that some of us
> sometimes choose to parse form data using a few lines of own code
> instead of using CGI.pm. You are lousy missionaries. ;-)
The main point (and it's been made many, many times) is that posting bad
code has consequences later on when Joe newbie does a Google search, finds a
piece of code which appears to work for them and they start using it
production code.
How many times have you heard, "I found this piece of Perl code. I don't
understand how it does it, but it works well for me." That is, it works
well until its bugs/incompatibilities rear their nasty head after the
environment or data it's running under changes.
Gunnar Hjalmarsson
> The main point (and it's been made many, many times) is that
> posting bad code has consequences later on when Joe newbie does a
> Google search, finds a piece of code which appears to work for them
> and they start using it production code.
Is that the main point?
I don't defend the use of "bad" code. But I do reserve me the right to
use code that does what I need it to do in *my* program, even if it
wouldn't work in anybody else's programs.
> How many times have you heard, "I found this piece of Perl code. I
> don't understand how it does it, but it works well for me." That
> is, it works well until its bugs/incompatibilities rear their nasty
> head after the environment or data it's running under changes.
Let's say that I use this regex:
if ( /abc\sxyz/ )
Somebody might object and say:
"It won't match unless 'abc' and 'xyz' are separated by exactly one
space, so you'd better do /abc\s*xyz/."
But if I explain the context in *my* program, letting him/her know
that I *know* that they are always separated by one space, my
explanation would probably be accepted.
Now, let's say that I have some code that deals with form data from
STDIN, including:
for (split /&/, $data)
If I would post it here, somebody would most certainly claim it to be
broken since I don't include ';' when splitting.
Then, if I would explain that in *my* program, data is only submitted
from a form using the POST method, some people here would *not* accept
my explanation, but still claim that the code is "broken", refer to
"Joe newbie" etc.
So, what's the difference between these two examples? Well, there is
absolutely no rational reason for claiming that there is a difference.
The simple explanation is that the latter example has to do with
something that *might* be done by help of CGI.pm, and for some
inscrutable reason CGI.pm has been made a 'sacred cow'.
Sacred cows should be slaughtered. Doing so make things *so* much
easier.
Randal L. Schwartz
Gunnar> Now, let's say that I have some code that deals with form data from
Gunnar> STDIN, including:
Gunnar> for (split /&/, $data)
Gunnar> If I would post it here, somebody would most certainly claim it to be
Gunnar> broken since I don't include ';' when splitting.
Gunnar> Then, if I would explain that in *my* program, data is only submitted
Gunnar> from a form using the POST method, some people here would *not* accept
Gunnar> my explanation, but still claim that the code is "broken", refer to
Gunnar> "Joe newbie" etc.
No. You don't have control over how data is submitted to your form.
And by limiting flexibility artificially, you are breaking legitimate
users who might want to create a bookmark for a particular form
submission, for example.
Why Hand Code a limited solution, when a flexible solution is available
to you with the simple phrase "use CGI qw(param);"?
It's not a sacred cow. It's the collective voices of people WHO HAVE
BEEN BURNED BY HAND CODING.
Get it? Voice of reason. Voice of experience. Pay attention.
Eric J. Roode
Hash: SHA1
Gunnar Hjalmarsson <nor...@gunnar.cc> wrote in news:bhntk8$1ak8t$1@ID-
184292.news.uni-berlin.de:
> Let's say that I use this regex:
>
> if ( /abc\sxyz/ )
>
> Somebody might object and say:
> "It won't match unless 'abc' and 'xyz' are separated by exactly one
> space, so you'd better do /abc\s*xyz/."
>
> But if I explain the context in *my* program, letting him/her know
> that I *know* that they are always separated by one space, my
> explanation would probably be accepted.
>
> Now, let's say that I have some code that deals with form data from
> STDIN, including:
>
> for (split /&/, $data)
>
> If I would post it here, somebody would most certainly claim it to be
> broken since I don't include ';' when splitting.
>
> Then, if I would explain that in *my* program, data is only submitted
> from a form using the POST method, some people here would *not* accept
> my explanation, but still claim that the code is "broken", refer to
> "Joe newbie" etc.
>
> So, what's the difference between these two examples? Well, there is
> absolutely no rational reason for claiming that there is a difference.
There certainly is. When you use a regular expression, you can be
reasonably certain who will use it under what circumstances. But you
have no idea who is going to link to your page and expect it to work with
semicolons as well as ampersands.
Don't believe me? A while ago, I was revising my "favorite links" page,
making it pass w3c's validation suites for strict HTML and CSS
compliance. You can't have naked ampersands in URLs in strict HTML. You
either have to code them as & (annoying in a URL), or change them to
semicolons (much easier to do, and easier to read). I found a whole mess
of sites -- some of them major, public sites -- that couldn't handle
semicolons instead of ampersands. Losers.
Apparently, many people think "nobody's going to access this page except
via the form that I have written, so I can do it any damn way I please."
That attitude limits the flexibility of people like me.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPz/TT2PeouIeTNHoEQLjUACghqj28tIeNoyq1dpmzpAl3+TQWx8AoME1
/N392tLwoYFI+GG8FerwHMZd
=Wj9S
-----END PGP SIGNATURE-----
Alan J. Flavell
> You can't have naked ampersands in URLs in strict HTML.
To nit-pick over terminology: you certainly _can_ have naked
ampersands "in URLs" - indeed, actual forms submission via GET
absolutely depends on it.
What you can't have are naked ampersands in URL *references* in HTML,
of the kind which occur in the attribute values for href= or src= etc.
in HTML.
I know this will seem pedantic, but failure to observe the distinction
between the URL itself, and a reference to it in HTML, has led in the
past to all kinds of confused URL-garbling.
> You either have to code them as & (annoying in a URL), or change
> them to semicolons (much easier to do, and easier to read). I found
> a whole mess of sites -- some of them major, public sites -- that
> couldn't handle semicolons instead of ampersands.
So any troll will be ready to tell us that they're doing no worse than
many successful high-profile commercial sites - so why are we
worrying?
> Losers.
I think so too, but there's always Sturgeon's Law on the side of our
detractors.
> Apparently, many people think "nobody's going to access this page except
> via the form that I have written, so I can do it any damn way I please."
Apparently, many people like the sense of power which such things give
them over their users (or at least -appear- to give them).
> That attitude limits the flexibility of people like me.
They would like that, you see.
No, I'm not trying to defend them, just to make an observation on the
perversity of human nature.
--
"If designers haven't done previous work for the web, they can come
to it with certain preconceptions." - Martin Tanton in uk.n.w.a
(a sample of the British art of understatement! -ed.)
Gunnar Hjalmarsson
>>>>>> "Gunnar" == Gunnar Hjalmarsson <nor...@gunnar.cc>
>>>>>> writes:
>
> Gunnar> for (split /&/, $data)
>
> Gunnar> If I would post it here, somebody would most certainly
> Gunnar> splitting.
>
> Gunnar> Then, if I would explain that in *my* program, data is only
> Gunnar> here would *not* accept my explanation, but still claim
> Gunnar> that the code is "broken", refer to "Joe newbie" etc.
>
> No. You don't have control over how data is submitted to your
> form.
The particular case I have in mind is the contact form program that
you access if you click the link in my sig, and that script explicitly
ignores submissions that are not POST.
> And by limiting flexibility artificially, you are breaking
> legitimate users who might want to create a bookmark for a
> particular form submission, for example.
Again, in this particular case, it would make absolutely no sense to
permit bookmark submissions.
> Why Hand Code a limited solution, when a flexible solution is
> available to you with the simple phrase "use CGI qw(param);"?
Again, in this particular case, I have absolutely no interest in
CGI.pm's flexibility as regards POST vs. GET. On the contrary, I have
an explicit interest *not* to allow GET submissions.
But I think we have drifted off topic now.
> It's not a sacred cow. It's the collective voices of people WHO
> HAVE BEEN BURNED BY HAND CODING.
>
> Get it? Voice of reason. Voice of experience. Pay attention.
Whether I "get it" depends on what exactly you mean by that.
I do pay attention. I listen respectfully. I take into account the
implied warnings. I take pains to be careful.
However, I reserve the right to decide, from case to case, if it's
motivated to make use of a module, whether it's CGI.pm or some other
module. I feel that I'm entitled to do so without automatically be
accused of using "bad" or "broken" code.
You are trying to prevent the clueless, careless programmers from
spreading bad code. That's fine. But do you really believe that you
make them less clueless and careless by enforcing dogmatic programming
rules in this group? I'm convinced that they just leave, if they ever
were here.
I'm not the only one who feels this way. I noticed that you replied to
Mark's message in the "perl zombies" thread, and I believe that he
expressed something similar. But most people with similar feelings
keep quiet and/or leave.
The only Perl book I have is the "camel". I do like it, and one
important reason is that the comments are shaded-off and respectful to
the reader's judge. I'd love it if more of the messages in this group
were written in the spirit of the "camel" comments. If that would
happen, some of the clueless and careless programmers might start
listen rather than being repelled.
Do *you* get what *I'm* trying to say, Randal?
Jonathan Stowe
>
> The particular case I have in mind is the contact form program that
> you access if you click the link in my sig, and that script explicitly
> ignores submissions that are not POST.
>
No it doesn't. Otherwise one wouldn't be able to follow the link. Of course
it is entirely appropriate that it should only accept a POST when the form
is submitted, but I am not sure what this has to do with the use or not of
some module.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
Gunnar Hjalmarsson
> Gunnar Hjalmarsson <nor...@gunnar.cc> wrote in
> news:bhntk8$1ak8t$1@ID- 184292.news.uni-berlin.de:
>
>> is absolutely no rational reason for claiming that there is a
>> difference.
>
> There certainly is. When you use a regular expression, you can be
> reasonably certain who will use it under what circumstances. But
> you have no idea who is going to link to your page and expect it to
> work with semicolons as well as ampersands.
Please see my reply to Randal where I explained that in the case I'm
thinking of, the script ignores GET submissions.
> Don't believe me?
Well, you are of course right in cases where submissions can be made
using GET (which they normally can). And you don't need to worry about
me in that respect. I wouldn't think of not splitting on both & and ;
in a 'normal' CGI script. And I do think.
Hey, even if I'm a relative beginner, I'm a *careful* programmer. And
I sometimes make use of modules, sometimes not. :)
Gunnar Hjalmarsson
> To nit-pick over terminology: you certainly _can_ have naked
> ampersands "in URLs" - indeed, actual forms submission via GET
> absolutely depends on it.
>
> What you can't have are naked ampersands in URL *references* in
> HTML, of the kind which occur in the attribute values for href= or
> src= etc. in HTML.
>
> I know this will seem pedantic, but failure to observe the
> distinction between the URL itself, and a reference to it in HTML,
> has led in the past to all kinds of confused URL-garbling.
Indeed an important distinction, Alan. To get it right, you do need to
be aware of that. In other words, you need to know what you are doing.
To return to my favorite topic: CGI.pm. Take a beginner who blindly
follows the firm advise from most regulars here, and start doing his
or her CGI by help of CGI.pm. One of the points with modules is that
you "shall not re-invent wheels", since experts already have taken
care of everything in a much better way than you ever could, right?
Okay, doesn't that mean a *greater* risk that s/he refrains from
learning the stuff you called our attention to above, compared to if
s/he had started to explore CGI by re-inventing a few wheels?
Just an (additional) thought.
Tim Hammerquist
> [...] I just don't understand why the regulars, who so strongly
> advocate the use of modules in general and CGI.pm in
> particular, provoke such reactions over and over again. It's a
> mystery to me why some people here make such a fuss about the
> fact that some of us sometimes choose to parse form data using
> a few lines of own code instead of using CGI.pm. You are lousy
> missionaries. ;-)
There are no laws, religious or otherwise, preventing you from
parsing your own form data.
However, if you choose to reinvent the wheel, especially on that
scale, you are likely to make several, possibly dangerous,
mistakes. Mistakes that have been fixed in CGI. Mistakes that,
if asked about in clpm, are not likely to be answered in any
manner except, "Why aren't you using CGI.pm? It fixed that
problem/bug/vulnerability months/years ago!"
But if you know better than the thousands of people who've
helped write and/or test CGI.pm or any of the dozens of other
recommended CGI-related modules on the CPAN...
Tim Hammerquist
--
Congratulations, you have just reinvented the wheel. *And* made it square.
-- Simon Cozens in comp.lang.perl.misc
Gunnar Hjalmarsson
> Gunnar Hjalmarsson <nor...@gunnar.cc> wrote:
>> The particular case I have in mind is the contact form program
>> that you access if you click the link in my sig, and that script
>> explicitly ignores submissions that are not POST.
>
> No it doesn't. Otherwise one wouldn't be able to follow the link.
Okay, my bad wording. I meant that it ignores *submitted data* that is
not submitted using POST. ;-)
> Of course it is entirely appropriate that it should only accept a
> POST when the form is submitted, but I am not sure what this has to
> do with the use or not of some module.
Not much. It was never my intention to discuss my contact form script
in detail, and as I mentioned, I think we have drifted off topic by
doing so.
Tassilo v. Parseval
> Randal L. Schwartz wrote:
>>>>>>> "Gunnar" == Gunnar Hjalmarsson <nor...@gunnar.cc>
>>>>>>> writes:
>> Gunnar> Then, if I would explain that in *my* program, data is only
>> Gunnar> submitted from a form using the POST method, some people
>> Gunnar> here would *not* accept my explanation, but still claim
>> Gunnar> that the code is "broken", refer to "Joe newbie" etc.
The real question remains: Why is your own solution better than CGI?
CGI works just as well when used in a very restricting compartement.
>> No. You don't have control over how data is submitted to your
>> form.
>
> The particular case I have in mind is the contact form program that
> you access if you click the link in my sig, and that script explicitly
> ignores submissions that are not POST.
>
>> And by limiting flexibility artificially, you are breaking
>> legitimate users who might want to create a bookmark for a
>> particular form submission, for example.
>
> Again, in this particular case, it would make absolutely no sense to
> permit bookmark submissions.
>
>> Why Hand Code a limited solution, when a flexible solution is
>> available to you with the simple phrase "use CGI qw(param);"?
>
> Again, in this particular case, I have absolutely no interest in
> CGI.pm's flexibility as regards POST vs. GET. On the contrary, I have
> an explicit interest *not* to allow GET submissions.
Easy:
use CGI qw/:cgi/;
if (request_method() eq 'GET') {
die_gracefully();
}
The fact that you only allow POST wont yet render CGI.pm useless.
There are myriads of 'good' explanations why a hand-rolled parser is
better than using CGI.pm. However, none has yet convinced me. This
module gives you all the flexibility you need...even if you want to
disallow flexibility explicitely.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
Rafael Garcia-Suarez
>
> use CGI qw/:cgi/;
>
> if (request_method() eq 'GET') {
> die_gracefully();
> }
That kind of thing is better done in an httpd.conf, for performance
reasons. But not everyone can tweak one's server config...
--
Unlinking is not *NIX
Gunnar Hjalmarsson
> Gunnar Hjalmarsson graced us by uttering:
>>[...] I just don't understand why the regulars, who so strongly
>>advocate the use of modules in general and CGI.pm in
>>particular, provoke such reactions over and over again. It's a
>>mystery to me why some people here make such a fuss about the
>>fact that some of us sometimes choose to parse form data using
>>a few lines of own code instead of using CGI.pm. You are lousy
>>missionaries. ;-)
>
> There are no laws, religious or otherwise, preventing you from
> parsing your own form data.
Okay, fine. :)
But since you replied to my initial post in this thread, Tim, please
allow me to call your attention to the topic I was *trying* to bring
up for discussion: It was *not* whether I'm *allowed* to write certain
code. It was rather the *tone* and the perceived *dogmatism* that is
used as soon as questions about the use of modules in general and
CGI.pm in particular are brought up.
Please see my latest reply to Randal, where I expanded on that topic.
> However, if you choose to reinvent the wheel, especially on that
> scale,
I have no intention to reinvent all the wheels that are covered by
CGI.pm. I'm actually using it in a couple of programs, and I'm likely
to use it more in the future, for instance if I need to handle file
uploads.
Another aspect: There may be very rational reasons for reinventing
wheels from time to time. See my reply to Alan in this thread, for
instance.
Tassilo v. Parseval
> To return to my favorite topic: CGI.pm. Take a beginner who blindly
> follows the firm advise from most regulars here, and start doing his
> or her CGI by help of CGI.pm. One of the points with modules is that
> you "shall not re-invent wheels", since experts already have taken
> care of everything in a much better way than you ever could, right?
> Okay, doesn't that mean a *greater* risk that s/he refrains from
> learning the stuff you called our attention to above, compared to if
> s/he had started to explore CGI by re-inventing a few wheels?
No, this risk you mention is not a risk but a virtue. I have some
experience with reading RFC and specs. My experience is that I always
get them wrong the first couple of times. They somehow and implicitely
assume that you already know the stuff which they are supposed to
explain. They are a valuable reference but they are inadquate for
learning a concept.
The reason is that they are normally very condensed. They don't talk
about the implication that every specification has on the
implementation. They assume that the reader is experienced enough to
figure them out on his own. An easy example:
Take a fictious RFC that explains some sort of request from a client to
a server. It says the request may have a length of no more than 4096
bytes (actual length stored in an environment variable). And now
consider a relatively inexperienced programmer who wants to write a C
library for this kind of protocol. He sees the limit of 4096 chars and
immediately starts off with:
static char request[4096];
void read_request (void) {
int len = atoi(getenv("REQUEST_LEN"));
read(fileno(stdin), (void*)request, len);
}
This code is standards-conformant. Unfortunately it also contains a
large security hole that can easily be triggered when the client sends a
string longer than the allowed 4096. And there you have a first nice
buffer-overrun.
This example is slightly contrived. It used C instead of Perl because it
is a little easier to construct vulnerabilites in C. But it's also
possible for Perl (things like creating and handling tmp-files securely
e.g. needs consideration in any language). Anyway, it shows that even
understanding something doesn't automatically mean you should be allowed
to program it. That should be left to those having enough experience in
avoiding CERT advisories.
Tassilo v. Parseval
A) that and B) a tweak to the server configuration would disallow it for
every script running on it (not sure about that actually, but I would
guess so).
I wonder though why one would want to allow only one method but not the
other one anyway. Especially when considering that CGI.pm has $POST_MAX
that can be used to restrict the length of requests.
Alan J. Flavell
> Indeed an important distinction, Alan. To get it right, you do need to
> be aware of that. In other words, you need to know what you are doing.
[...]
> Okay, doesn't that mean a *greater* risk that s/he refrains from
> learning the stuff you called our attention to above, compared to if
> s/he had started to explore CGI by re-inventing a few wheels?
I think you're confusing the distinction between individual learning
studies, and practical solutions fit for a real-world CGI situation.
Both have their place in the scheme of things, but one needs to be
clear which is which.
When I started this game, back in Perl4 days, I used to write my own
decoding - copying what I would now categorise as cargo-cult code that
I found in existing scripts. As I learned more about the
practicalities, I started to use cgi-lib.pl. Subsequently I learned
yet more, and started to make the acquaintance of CGI.pm
Without wanting to brag, I think I could fairly say that I understand
CGI and HTTP issues at a level somewhat above the average for this
group - even if my Perl coding is rather pedestrian[1] - but that only
gives me even more reason to recommend using peer-reviewed modules to
anyone who's willing to ask. And when it comes to CGI, "warts and
all", CGI.pm is basically _the_ peer reviewed solution. Just look at
the fuss there's been about a typo in version 2.99. Where would you
enlist that amount of effort to help with some obscure typo in your
own hand-spun script, riddle me that?
all the best
[1] "Physicists code FORTRAN in any language" - original attribution
not known.
Gunnar Hjalmarsson
> The real question remains: Why is your own solution better than CGI?
That is not the question at all, since I never claimed that it is.
Claiming that was not the purpose with starting this thread.
I'm asking for some respect. Yes, modules *are* a good concept. Yes, I
*do* use modules. But ... let me quote a part from the message you
replied to that you did not quote:
> Gunnar Hjalmarsson wrote:
>> I reserve the right to decide, from case to case, if it's
>> motivated to make use of a module, whether it's CGI.pm or some other
>> module. I feel that I'm entitled to do so without automatically be
>> accused of using "bad" or "broken" code.
> CGI works just as well when used in a very restricting compartement.
I know. Actually, a few months ago the regulars in this group
pursuaded me to use CGI for that particular program, which btw is a
CPAN module under the CGI:: namespace (CGI::ContactForm), so I finally
changed it. :)
As I mentioned in another post, it was never my intention to discuss
that program in detail. In a reply to Tintin I gave two *examples* of
code in order to illustrate my thesis that some kind of Perl code can
easily be discussed here in a sober manner, while other kind of code
can not.
Unfortunately I think that the reactions to my simple
split /&/, $data
example have confirmed the thesis quite well. :(
CGI.pm is a sacred cow. Slaughter the sacred cow! (But keep CGI.pm, of
course...)
Tim Hammerquist
> please allow me to call your attention to the topic I was
> *trying* to bring up for discussion:
The initial post of a thread is generally where discussions are
brought up. If a new discussion is desired and/or needed, it's
typically done in a new thread.
I've read this thread. I just chose to reply to this post.
> Please see my latest reply to Randal...
Have done.
> See my reply to Alan...
Have done.
Let me summarize this thread for anyone who might be joining us
late.
OP == Original Poster.
EE == Everyone Else
OP: I want to do A.
EE: Why? It's a bad idea. Use B.
OP: But with A I can do C.
EE: I see why you might want to do A, but B can already do C.
OP: But B can't do C the same way A can.
EE: No, you're right. It does it better, safer, and cleaner than A.
OP: I'm not impressed with all the reasoning and experience
you've shared with me.
EE: Um, ok.
OP: Why don't you see things my way?
EE: We've been doing this longer and heard many arguments from
many other people and have still not been convinced.
OP: You guys are just arrogant bastards.
EE: Possibly, but we've earned our arrogance.
OP: But why can't I do A?!
EE: You can. We just think it's a bad idea and can't see
supporting you in what has previously always been a fatally
flawed endeavour.
OP: But WHY don't you want to help me?
EE: You're not asking for help.
OP: But why won't you believe in my obviously well-thought-out ideas?
EE: Because we don't think you've really thought them out far enough.
OP: You guys are a bunch of fascists! See my replies where I say
as much to regular posters D, E, and F.
EE: No thanks.
Tim Hammerquist
--
Q: Puff, what is best in sys admin?
A: To crush your script kiddies, see them coredump before you,
hear the stack protector warnings of their failed overflows.
-- From an OpenBSD Journal post
Alan J. Flavell
> I wonder though why one would want to allow only one method but not the
> other one anyway.
In principle, the key to that is idempotence. Although there can be
other practical issues involved.
If you're implementing a form which performs a non-idempotent action,
such as casting a vote, ordering a flight ticket, etc. then it would
be wise to refuse to accept a GET submission. I think you'll find
more about it in RFC2616.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
> Especially when considering that CGI.pm has $POST_MAX
> that can be used to restrict the length of requests.
With respect, I think you're focussing on a peripheral issue.
Abigail
MMMDCXXXVIII September MCMXCIII in <URL:news:bhot4i$27o$1...@nets3.rz.RWTH-Aachen.DE>:
,,
,, The real question remains: Why is your own solution better than CGI?
,, CGI works just as well when used in a very restricting compartement.
Actually, it has always amazed me why using a dinosaur module like CGI
is considered "good programming" if all you need is parameter parsing.
I'm not at all surprised that people use the commonly see 'read_parse'
subroutine (I wonder why people keep calling that 'handrolled' - it's the
same code you see over and over again. This is code reuse, although it's
code that doesn't cover all cases (not that I can recall ever seeing a
posting here complaining that not all cases are covered)). 'read_parse'
is about 10 lines of code, and not to hard to understand. The manual of
CGI.pm is 3226 lines. And it's doing all kinds of stuff that isn't at
all CGI related. I'd expect a new version of CGI.pm that sends out
mail any day now.
I remember the days when you could write the entire CGI specification
on less than one sheet of A4 paper. CGI is *simple*, but CGI.pm isn't.
And yes, I've "rolled my own parsing" as well, and it certainly didn't
cover all cases either. It doesn't always have to.
Abigail
--
$=-=4*++$|;{print$"x--$==>"\@\x7Fy~*kde~box*Zoxf*Bkiaox \r"
^
$/x24if!select$,,$,,$,,join+q=.==>$^W=>$|;$=&&redo}sleep$|;
Gunnar Hjalmarsson
> On Sun, Aug 17, Gunnar Hjalmarsson inscribed on the eternal scroll:
>> Indeed an important distinction, Alan. To get it right, you do
>> need to be aware of that. In other words, you need to know what
>> you are doing.
>
> [...]
>
>> Okay, doesn't that mean a *greater* risk that s/he refrains from
>> learning the stuff you called our attention to above, compared to
>> if s/he had started to explore CGI by re-inventing a few wheels?
>
> I think you're confusing the distinction between individual
> learning studies, and practical solutions fit for a real-world CGI
> situation.
In a way I did mix them up, and that was intentionally.
How often do all the regulars, who so energetically advocate the use
of modules, mention the _desirable_ in "reinventing wheels" in order
to gain knowledge?
> Without wanting to brag, I think I could fairly say that I
> understand CGI and HTTP issues at a level somewhat above the
> average for this group
No doubt you do.
I wonder if that had been the case if Perl 5 and CGI.pm had been
available when you started, while experienced programmers had enforced
you to use CGI to begin with. ;-)
Abigail
MCMXCIII in <URL:news:Xns93DA9A7DF7...@206.127.4.25>:
==
== Apparently, many people think "nobody's going to access this page except
== via the form that I have written, so I can do it any damn way I please."
== That attitude limits the flexibility of people like me.
What a sillyness. A form defines an interface. It tells you which input
names there are. It tells you the URL to submit it to. It tells you
whether to use GET or POST.
Now, you as a submitter may be flexible, but it's silly to assume that
if you invent your own input names, treat radio-buttons as text input
or make up your own URL to submit to, that it's going to work.
It's like normal programming. If you use a library, stick to its API.
If you make something up, don't be surprised it won't work.
Abigail
--
perl -wle'print"Кхуф бопфиет Ретм Ибглет"^"\x80"x24'
Gunnar Hjalmarsson
> Actually, it has always amazed me why using a dinosaur module like
> CGI is considered "good programming" if all you need is parameter
> parsing.
<snip>
> And yes, I've "rolled my own parsing" as well, and it certainly
> didn't cover all cases either. It doesn't always have to.
Wow, a _regular_ who admits that she relies on her own judge from time
to time.
Thanks, Abigail! :)
ko
> >>>>> "Gunnar" == Gunnar Hjalmarsson <nor...@gunnar.cc> writes:
>
> Gunnar> Now, let's say that I have some code that deals with form data from
> Gunnar> STDIN, including:
>
> Gunnar> for (split /&/, $data)
>
> Gunnar> If I would post it here, somebody would most certainly claim it to be
> Gunnar> broken since I don't include ';' when splitting.
>
> Gunnar> Then, if I would explain that in *my* program, data is only submitted
> Gunnar> from a form using the POST method, some people here would *not* accept
> Gunnar> my explanation, but still claim that the code is "broken", refer to
> Gunnar> "Joe newbie" etc.
>
> No. You don't have control over how data is submitted to your form.
> And by limiting flexibility artificially, you are breaking legitimate
> users who might want to create a bookmark for a particular form
> submission, for example.
>
> Why Hand Code a limited solution, when a flexible solution is available
> to you with the simple phrase "use CGI qw(param);"?
>
> It's not a sacred cow. It's the collective voices of people WHO HAVE
> BEEN BURNED BY HAND CODING.
>
> Get it? Voice of reason. Voice of experience. Pay attention.
I'm not sure that the form example was a good way to make your point,
Gunnar. Anyone can submit anything they want to a form. In the
simplest case, someone makes a local copy of the form, changes all the
parameters locally, and then submits the edited copy to the web
server. Also, look at the LWP bundle of modules on CPAN
(http://search.cpan.org/author/GAAS/libwww-perl-5.69/lib/LWP.pm),
especially LWP::UserAgent, to see how easily it is to programmatically
send arbitrary data with forms, not to mention arbitrarily set HTTP
REFERER, USER_AGENT, etc.
On a side note, I'm a self-taught coder and semi-regular 'lurker' on
this group. I rarely post, and use the discussions as a learning tool.
I search the group pretty much exclusively using Google, not a
newsreader - I know, I probably should be using a newsreader...
Anyway, this guy has created a *lot* of noise lately. It's probably
presumptuous of me to request/suggest, especially since some of the
posts haven't even been civil, but could the experts/regulars just
ignore any of his subsequent posts? With all of your knowledge to
share, it just seems like a waste to continue any existing/new
threads. He seems pretty set in *his* ways, not the other way around,
which is what has been implied.
I would think even newbies can figure out what's going on with someone
who answers his own post/rants:
(http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=bho4uf%244i2%241%40ichaos.ichaos-int&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.perl.misc).
Thanks - keith
Gunnar Hjalmarsson
> I'm not sure that the form example was a good way to make your
> point, Gunnar. Anyone can submit anything they want to a form.
True. But the script does not necessarily need to parse anything.
Tassilo gave an example of that, btw.
Anyway, I won't prolong the discussion about my form example.
> Anyway, this guy has created a *lot* of noise lately. It's probably
> presumptuous of me to request/suggest, especially since some of
> the posts haven't even been civil, but could the experts/regulars
> just ignore any of his subsequent posts? With all of your knowledge
> to share, it just seems like a waste to continue any existing/new
> threads. He seems pretty set in *his* ways, not the other way
> around, which is what has been implied.
Hrrmm... With all respect, Keith, could you please clarify who you are
referring to with the expression "this guy"? My name is Gunnar, I
started this thread, and I'm not the same person as is mentioned in
the subject line of this thread.
Gunnar Hjalmarsson
Even if I disapprove of the accuracy of your summary, I hope you had
fun when you wrote it.
Eric J. Roode
Hash: SHA1
"Alan J. Flavell" <fla...@mail.cern.ch> wrote in
news:Pine.LNX.4.53.03...@lxplus003.cern.ch:
> On Sun, Aug 17, Eric J. Roode inscribed on the eternal scroll:
>
>> You can't have naked ampersands in URLs in strict HTML.
>
> To nit-pick over terminology: you certainly _can_ have naked
> ampersands "in URLs" - indeed, actual forms submission via GET
> absolutely depends on it.
>
> What you can't have are naked ampersands in URL *references* in HTML,
> of the kind which occur in the attribute values for href= or src= etc.
> in HTML.
You're right, of course; I was speaking loosely.
>
>> Losers.
>
> I think so too, but there's always Sturgeon's Law on the side of our
> detractors.
:-)
>
>> That attitude limits the flexibility of people like me.
>
> They would like that, you see.
Nah, I think they just don't think.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0AjemPeouIeTNHoEQJJ7gCgmOehpLwiZ9MhlP7A+KQUyGaOM54AoJXV
TkknFlRHNEct1fOMfiz7PO11
=bntV
-----END PGP SIGNATURE-----
Tim Hammerquist
>> Let me summarize this thread for anyone who might be joining us
>> late.
>>
>> OP == Original Poster.
>> EE == Everyone Else
>>
>
> Even if I disapprove of the accuracy of your summary, I hope
> you had fun when you wrote it.
The OP in this case is a composite of you, hudson, and the dozens
of other plaintiffs I've seen make the same arguments in the last
5 years. So I realize you aren't personally responsible for all
the above statements, but did I leave anything out? Any other
arguments you plan to bring to the table I might include?
And I did get notable enjoyment out of this, thanks.
Tim Hammerquist
--
When angry, count four; when very angry, swear.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
Gunnar Hjalmarsson
> The OP in this case is a composite of you, hudson, and the dozens
> of other plaintiffs I've seen make the same arguments in the last 5
> years.
Is he? In that case, the 'summary' was falsely introduced, so you'd
better post a corrective message as a direct reply to your own message
which includes the summary.
> So I realize you aren't personally responsible for all the above
> statements, but did I leave anything out?
You did *not* include *any* of the points I have been trying to make
in this thread, so I find it hard to believe that you aren't just
stating your own opinion in a bantering way.
> Any other arguments you plan to bring to the table I might include?
No, my arguments don't fit in your table.
This is *my* summary of what I have been trying to say:
I'm an adult. I make my own decisions. Of course I listen to advise
from people who are more knowledgable and/or experienced than I am,
but in the end I rely on my own judge and make my own decisions. This
is the case also when I'm writing a Perl program and decide whether
it's appropriate to use a module for solving a particular task.
Quite a few of the 'regulars' in clpmisc occationally act as if the
typical reader is a kid. They keep repeating very dogmatic programming
rules, and meet everyone who don't completely 'obey' in a patronizing
way. That's bad. As an adult I find it insulting from time to time.
I do appreciate all the knowledge and advise that the regulars
generously deliver here, but I don't appreciate the 'tone' that is
occasionally used when doing so.
I believe that clpmisc would be an even better group, if some advises
were delivered in a more respectful way, taking into consideration
that the typical reader is an adult with the ability to consider a
good advise and make a decision based on their own judgement.
ko
> referring to with the expression "this guy"? My name is Gunnar, I
> started this thread, and I'm not the same person as is mentioned in
> the subject line of this thread.
Sorry Gunnar, I was referring to the subject of the thread, the
recently 'popular' Hudson.
keith
Tim Hammerquist
>> The OP in this case is a composite of you, hudson, and the
>> dozens of other plaintiffs I've seen make the same arguments
>> in the last 5 years.
>
> Is he? In that case, the 'summary' was falsely introduced, so
> you'd better post a corrective message as a direct reply to
> your own message which includes the summary.
No. I said "OP == Original Poster", which is true. The
composite is based on the original poster of all such articles,
including the OP of this thread.
> This is *my* summary of what I have been trying to say:
>
> I'm an adult.
To the group: Did anyone here challenge Gunnar's adulthood?
> Of course I listen to advise from people who are more
> knowledgable and/or experienced than I am, but in the end I
> rely on my own judge and make my own decisions.
Good. So why are you still arguing in usenet?
> Quite a few of the 'regulars' in clpmisc occationally act as if
> the typical reader is a kid. They keep repeating very dogmatic
> programming rules, and meet everyone who don't completely
> 'obey' in a patronizing way. That's bad. As an adult I find it
> insulting from time to time.
I find the willingness of the group to keep repeating things the
readers don't seem to grasp is a sign of patience. YMMV.
> I do appreciate all the knowledge and advise that the regulars
> generously deliver here, but I don't appreciate the 'tone' that
> is occasionally used when doing so.
comp.lang.python may be the answer here. See my post in another
thread where I say as much.
> I believe that clpmisc would be an even better group, if some
> advises were delivered in a more respectful way, taking into
> consideration that the typical reader is an adult with the
> ability to consider a good advise and make a decision based on
> their own judgement.
Bernard El-Hagin has come to the same conclusion and has posted
an aid to help you... 2 years ago. I won't waste your time
mentioning how this confirms how original your claims aren't.
(Oops. I just did.) But it just might help you:
http://groups.google.com/groups?th=a378813d05423a80
HTH. HAND.
Tim Hammerquist
--
It's astonishing how much trouble one can
get oneself into, if one works at it.
-- Destruction, The Sandman
Tassilo v. Parseval
> Tassilo v. Parseval (tassilo....@rwth-aachen.de) wrote on
> MMMDCXXXVIII September MCMXCIII in
> <URL:news:bhot4i$27o$1...@nets3.rz.RWTH-Aachen.DE>:
> ,,
> ,, The real question remains: Why is your own solution better than CGI?
> ,, CGI works just as well when used in a very restricting compartement.
>
>
> Actually, it has always amazed me why using a dinosaur module like CGI
> is considered "good programming" if all you need is parameter parsing.
Using it doesn't automatically turn you into a good programmer. Right so
far.
> I'm not at all surprised that people use the commonly see 'read_parse'
> subroutine (I wonder why people keep calling that 'handrolled' - it's the
> same code you see over and over again. This is code reuse, although it's
> code that doesn't cover all cases (not that I can recall ever seeing a
> posting here complaining that not all cases are covered)).
The routine used is indeed commonly seen (with some slight variations).
What strikes me though is the fact that it is always this incomplete
version. I am not sure whether most people who copy and paste this code
are aware of that.
> 'read_parse' is about 10 lines of code, and not to hard to understand.
> The manual of CGI.pm is 3226 lines. And it's doing all kinds of stuff
> that isn't at all CGI related. I'd expect a new version of CGI.pm that
> sends out mail any day now.
I wont argue about that. I don't like the interface of CGI either. The
module is heavy, bloated and just does too much. Since I hardly do CGI
things I always end up grepping through the perldocs to find a
particular function when I need it.
> I remember the days when you could write the entire CGI specification
> on less than one sheet of A4 paper. CGI is *simple*, but CGI.pm isn't.
Actually, CGI.pm is very simple. To realize that however you need to
have read the whole documentation. The module lacks a function
reference. The documentation is more like a tutorial for me (which
becomes extremely tedious to work with once you've understood how it
works).
> And yes, I've "rolled my own parsing" as well, and it certainly didn't
> cover all cases either. It doesn't always have to.
But you knew in beforehand which cases you needed to cover. I find the
crowd of people arguing against CGI disturbing. With the exception of
you and Gunnar, those are mostly beginners or - and that is worse since
it makes all my alarm bells ring - Godzilla. These discussions follow a
certain scheme: Beginner argues that CGI parsing is simple, regulars
contradict. That goes on for a while till beginner triumphantly shows a
variation of 'read_parse'. When it's pointed out to him that this in
fact is not CGI because, on average, it just covers half of it, he
begins to confine his requirements to POST, '&' as the only separator
and so on. Had he done that before exhibiting the code, it would have
been alright.
Tassilo v. Parseval
> On Mon, Aug 17, Tassilo v. Parseval inscribed on the eternal scroll:
>
>> I wonder though why one would want to allow only one method but not the
>> other one anyway.
>
> In principle, the key to that is idempotence. Although there can be
> other practical issues involved.
>
> If you're implementing a form which performs a non-idempotent action,
> such as casting a vote, ordering a flight ticket, etc. then it would
> be wise to refuse to accept a GET submission. I think you'll find
> more about it in RFC2616.
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Interesting. It's the first time I hear about idempotence in relation to
HTTP.
>> Especially when considering that CGI.pm has $POST_MAX
>> that can be used to restrict the length of requests.
>
> With respect, I think you're focussing on a peripheral issue.
Possibly so. I didn't know about the above distinction.
Did I already mention that I seldom program in the CGI (and HTTP)
compartment? ;-)
Tintin
"Gunnar Hjalmarsson" <nor...@gunnar.cc> wrote in message
news:bhntk8$1ak8t$1...@ID-184292.news.uni-berlin.de...
> Tintin wrote:
> > The main point (and it's been made many, many times) is that
> > posting bad code has consequences later on when Joe newbie does a
> > Google search, finds a piece of code which appears to work for them
> > and they start using it production code.
>
> Is that the main point?
One of the main points at least.
>
> I don't defend the use of "bad" code. But I do reserve me the right to
> use code that does what I need it to do in *my* program, even if it
> wouldn't work in anybody else's programs.
I'm not arguing that you don't have the right to use whatever code you like
in *your* program. The problem occurs when someone either posts their bad
code as a solution to someones problem/question or like our new troll, they
claim they know it all and post their code as an example of their
"excellence".
Gunnar Hjalmarsson
> I'm not arguing that you don't have the right to use whatever code
> you like in *your* program. The problem occurs when someone either
> posts their bad code as a solution to someones problem/question or
> like our new troll, they claim they know it all and post their code
> as an example of their "excellence".
Then we are apparently not talking about the same thing. A comment on
the issue you are addressing:
Of course it's important that _answers_ or _model samples_, that are
posted here or in other similar forums, are not "bad". And if such
code occationally is bad, it will most certainly be followed up with
comments that call the readers' attention to that fact.
If your "Joe newbie" is so clueless so that he Googles to a random
piece of code, copies it and uses it without even reading the
accompaning comments, it's sad. But it would be a too big burden to
take responsibility for people that are so clueless, wouldn't it?
Jonathan Stowe
>
> If your "Joe newbie" is so clueless so that he Googles to a random
> piece of code, copies it and uses it without even reading the
> accompaning comments, it's sad. But it would be a too big burden to
> take responsibility for people that are so clueless, wouldn't it?
>
But then when this person disovers that the code that they have
copied from some random place on the web doesn't work they will
invariably turn up here or somewhere similar and a certain percent
of the time they will react badly to being told that downloading random
crap code is a bad thing to do. So in the end we end getting to deal with it.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
Gunnar Hjalmarsson
> Gunnar Hjalmarsson <nor...@gunnar.cc> wrote:
>> If your "Joe newbie" is so clueless so that he Googles to a
>> random piece of code, copies it and uses it without even reading
>> the accompaning comments, it's sad. But it would be a too big
>> burden to take responsibility for people that are so clueless,
>> wouldn't it?
>
> But then when this person disovers that the code that they have
> copied from some random place on the web doesn't work they will
> invariably turn up here or somewhere similar and a certain percent
> of the time they will react badly to being told that downloading
> random crap code is a bad thing to do. So in the end we end
> getting to deal with it.
Maybe. And - what's your recipe? A global police force, covering www
and Usenet, who removes every piece of "random crap code" that people
post?
Tim Hammerquist
> that are posted here or in other similar forums, are not "bad".
> And if such code occationally is bad, it will most certainly be
> followed up with comments that call the readers' attention to
> that fact.
I agree. This is largely true with only two considerations:
1) When Josie User (hopefully) uses Google Groups to answer her
questions before posting to the group, she may see this
wonderful little script that Cory Coder posted and decide to
use it, never bothering to click on the "Complete Thread"
button and see how the next person pointed out how it would
allow Sid "ph34r m3" Luser to read her private mail and make
her dishes fly out of the cupboard to the tune of Helter
Skelter.
2) Often the person whose code is deemed "bad" refuses to accept
this and keeps arguing their point using increasingly
contrived contexts until theirs is the only possible answer,
by which time half the group has killfiled them.
The latter does not seem to be avoidable, and is more a nuisance
than anything else. The former rather more important, and the
only advice I can offer in this regard is, "When googling, please
read the entire thread!"
Tim Hammerquist
--
Two of the most famous products of Berkeley are LSD and Unix.
I don't think that this is a coincidence.
-- Anonymous
Gunnar Hjalmarsson
> wow....I am very afraid to even start to read this thread ;-)
No need to. Despite the subject line, it's (almost) not about you.
Btw, hope you don't mind my choice of subject line. After all, it was
all your posts that inspired me to start the thread. :)
> by the way, the hudson river is right outside my door. I'm thinking
> of putting my computer on a little raft and set it out to sea...
Don't. You do need to hold back you posts a bit, but there should be
less drastic methods.
Matt Garrish
"Tim Hammerquist" <t...@vegeta.ath.cx> wrote in message
news:slrnbk02b...@vegeta.ath.cx...
> OP: You guys are a bunch of fascists! See my replies where I say
> as much to regular posters D, E, and F.
> EE: No thanks.
>
You should perhaps read some of Gunnar's posts. It's only too bad the
courtesy and thought he puts into his messages isn't always matched by those
responding.
Matt
Matt Garrish
"hudson" <scripts_you_k...@hudsonscripting.com> wrote in message
news:f343kv8u2sq56n5k4...@4ax.com...
>
> I have just encountered this thought of "we must post good code to
> protect those who seach google" here in this group...I must of seen it
> several times in the last few days. I think it is part of the
> mythology of this group.
>
Deep thoughts run shallow outside Perl in this group. In theory, their
protection of the group should have stopped you from posting. And for all
the derision heaped on innocent off-topic posters, the number of replies to
your posts say something about the duplicitous nature of some people. That
said, you are pushing the boundaries of good taste by clogging the group
with your posts.
Matt
David H. Adler
>
> I use google search, and I think anyone in their right mind does
> several searches, reads several posts, trys things out and chooses the
> best solution.
>
> Many times I have used google and come up with bad answers or things
> that don't work...that is part of the process.
The problem is that many people, beginning programmers especially, are
not necessarily the best judges of what the "best solution" is. Leaving
a bad solution unchallenged can give the impression that it's not
actually bad... which is bad.
Bad is a *three* letter word. :-)
dha, and, no, I don't know what I mean by that last bit either... but
I'm amused. *shrug*
--
David H. Adler - <d...@panix.com> - http://www.panix.com/~dha/
If you have a square-pattern aura, you will be shot to death by Federal
agents. - NYC street lunatic with a red hat.