TIP: How to post good questions
I R A Aggie
Repost, time..and yes, Olga, there *are* stupid questions.
Date: 09 Nov 1995 02:57:30 GMT
From: m...@plover.com (Mark-Jason Dominus)
Subject: Re: system() question
There are a lot of reasons, many of which get repeated over and
over again, many of which don't. Some of the reasons you hear a lot
are: Questions are incoherently phrased. Questions have the form `my
code doesn't work' and don't include the code. Questions include the
code, and it's 200 lines long, and comp.lang.perl is not a debugging
service. Nobody knows the answer to the question. The question is so
badly punctuated that nobody can bear to read it. Questions aer
written by a non-native speaker of English and the native speakers who
are trying to understand it can't. (That's a shame, but it does
happen. I often wish that these people would post in their native
languages. I'd love to see more discussion in languages other than
English. Some Dutch guy tried posting all his comp.lang.c articles in
Dutch a few years ago, and all the Americans flamed him. How
humiliating for me!)
Apart from these oft-mentioned reasons are many others that are
not so often discussed, because anyone who tries to bring them up gets
flamed. But it's the truth: I know the reason I don't answer more
questions is because so many of them questions are so damn stupid.
They're stupid in a lot of different ways, but they're still stupid.
I don't want to suggest that that's why your questions go unanswered.
I don't know what you're asking. No doubt the reason your questions
go unanswered is because they're so deep and interesting that nobody
really knows the answer.
The most common stupid question is the one from someone who has
some high-level problem that they need solved. They have an idea that
they'd like to do it in perl, and they don't really know perl. So
instead of learning perl, they post to comp.lang.perl.misc.
Now don't get me wrong. I don't have any problems answering the
questions of someone who's trying to learn perl. I love THOSE
qusetions. But these people don't seem to be asking useful questions
for that.
Today, for example, I saw a question from a guy who wants to get a
list of hostnames out of nslookup. `How do I do that?' he says. And
it's hard to know what to make of that. What does he mean? Does he
not know how to open a pipe? Is his `open' command failing? What's
going on here? I can't give a useful answer without understanding the
problem. Having your `open' fail is a problem. Wanting to list
hostnames is not a problem; it's a desire.
Here are some similar questions that would have made more sense to me:
1. ``I'm a lazy asshole and I can't be bothered to learn to
program myself, but I know if I post here you'll give me
something for free.''
(OK, fair enough. At least I can send him a rate card.)
2. ``I'm trying to use `open' to talk to nslookup, but...
...here's my code; what's wrong?''
(Good question.)
3. ``I know perl has a `system' command for running programs,
but I can't see how to get my commands into nslookup
once I have run it.''
(Good question.)
4. ``I'm trying to use `getprotobynumber' to talk to nslookup...''
(Good question.)
See, I'm not just biting people's heads off, here. #4 is a good
question, because it gives me something to work with. OK, he has a
very weird idea about interprocess communication, but that's
ignorance, and that's what we're here to correct. He doesn't know
about `open'; I can refer him to the manual.
Here's another example: Some guy wants to assemble a list of email
addresses . ``How do I do that?'' he wants to know. Well, duh. Get a
big pad of paper and read news for a couple days and write down all
the addresses you see. Problem solved. What's it doing in
comp.lang.perl?
Oh, you wanted to do it in perl. Well, I guess I'd open a socket
to the NNTP server and send it some XHDR commands for the `From'
lines. But that's not Perl; you could do that in any language. I
could do it in Bourne Shell for you if I'm allowed to use a little
external thingie to handle the socket parts for me. What's it doing
in comp.lang.perl?
Oh, you wanted us to write the program for you? Wait, let me send
you my rate card.
Someone posted yesterday asking how to get the data from a file
where the start and end of the data is marked by keywords. Same thing
going on here. ``Well, here's how you solve your problem: First you
go take an introductory class in programming and learn to write
programs in some language. Then you go to the bookstore and buy this
book by Wall and Schwartz, it's really good. Read the book carefully
and try out the examples. Then if you still have general questions
like `How do I do this' instead of `I thought that this code would do
X but instead it does Y' you hire a professional to write your program
for you. Or you could just skip right to step 3. Want my rate
card?''
The worst stupid questions are the ones that come from people who
have no business asking them. The most perfect example of this that I
could have imagined was in comp.unix.questions a couple of years ago.
Some guy came and asked how you could tell if a file is a hard link.
My jaw flapped open and it's stayed open since then. I couldn't have
been any more stumped if he'd asked why Bodhidharma came from the
West. What do you say to this guy? Do you tell him the truth, that
all files are hard links, that even symbolic links are hard links?
He's not going to understand you; you might as well keep your mouth
shut. Do you tell him the truth, that the answer won't do him any
good because he doesn't know what a hard link is, so why did he bother
asking in the first place? No, that'll just make him mad. I followed
that message for the next couple weeks, and nobody said anything.
What could you say? The guy had no business asking the question and
no use for the answer. Maybe the right answer would have been to cut
off his finger or something. I dunno.
Some questions get ignored because they're boring. Someone asked
today how to compare two variables (I assumme he means the contents of
those variables) to see if they're exactly the same. You've gotta be
in an awfully good mood to take the time to answer that. Maybe
someone will. Maybe I will.
If I answer that one today, maybe he'll be back tomorrow asking
how to check to see if two variables contain different values. Maybe
I won't. What I find incredible is that if you tell these people to
go read the manual and come back in two weeks, you sometimes get
jumped on for not being helpful to beginners. Bah. If everyone told
these people to go read the manual, they'd eventually figure out that
that's what you have to do ,and then I wouldn't have to spend so much
of my life dealing with incompetent programmers.
Some questions are logically nonsensical because the querent
thinks they know more than they do. A lot of these have the form
``How do I use X to accomplish Y?'' There's nothing wrong with this,
except that sometimes X is a chocolate-covered banana and Y is the
integration of European currency systems. I always get stuck on
these, probably because I can't get rid of the idea that the person
really has a good reason for wanting to use X. I know a half-dozen
easy simple ways to accomplish Y, but I can't imagine what X has to do
with it. This is a problem for me in my day job, too. Clients are
always saying to me ``We want to use product X to do multimedia
development on the world-wide web,'' and all I can think is ``Well,
gee, what would you want to go and do that for?'' Sometimes it turns
out that they want to do it because they want to impress the
manufacturers of X, and I don't work on those jobs.
The flip side of this is a questions like ``I want to accomplish
X, but I don't want to use Y. What can I use instead?'' Which,
again, is sometimes reasonable, and then sometimes X is closing a
filehandle and Y is the `close' function.
The questions I like the best are the ones that go like this:
``I want to accomplish X.
I thought that the following code fragment would do it:
...
But instead it does Y.
Why is that?''
This one is also pretty good:
``I want to accomplish X.
I thought I might be able to use facility Y.
But Y doesn't seem like it's quite right,
because of Z.
What should I use instead of Y, or how can I overcome Z?''
When I ignore these, it's usually because I don't know the answer.
There were an awful lot of them today. It makes me very happy.
There you go; a 160-line dissertation on why questions go unanswered.
Now don't let me hear you saying nobody ever answers your questions.
F.Quednau
bir...@my-dejanews.com wrote:
>
> Don't you think that this article - may be cut down a bit - is
> worth to be auto-posted "very often" with a more "aggressive"
> subject line ?
>
I agree. This article should appear more often. It makes a lot of sense.
How about : How to post Good Questions in c.l.p.m.
--
____________________________________________________________
Frank Quednau
http://www.surrey.ac.uk/~me51fq
________________________________________________
I R A Aggie
In article <359217E8...@nortel.co.uk>, "F.Quednau"
<qued...@nortel.co.uk> wrote:
+ bir...@my-dejanews.com wrote:
+ >
+
+ > Don't you think that this article - may be cut down a bit - is
+ > worth to be auto-posted "very often" with a more "aggressive"
+ > subject line ?
+ I agree. This article should appear more often. It makes a lot of sense.
I'm open to suggestions. Remember, I didn't write the article, merely
reposted it. I already have a perl script that can automagically repost
an article, so that's already done.
Perhaps it would be better to post it occasionally, and slap it up on
www.perl.com somewhere, with pointers to the website in the other
informational autoposts that show up here.
James
Mark-Jason Dominus
In article <359217E8...@nortel.co.uk>,
F.Quednau <qued...@nortel.co.uk> wrote:
>I agree. This article should appear more often. It makes a lot of sense.
It would be OK with me if someone wanted to do that.
I would like to fix the typoes and make a couple of minor wording
changes first, though.
Mark-Jason Dominus
In article <fl_aggie-240...@aggie.coaps.fsu.edu>,
I R A Aggie <fl_a...@thepentagon.com> wrote:
>Dominus wrote:
>>``How do I use X to accomplish Y?'' There's nothing wrong with this,
>>except that sometimes X is a chocolate-covered banana and Y is the
>>integration of European currency systems.
A less abominable example of this that comes up all the time is
I have an array of strings. How do I check whether the array
contains a certain string?
Usually (not always, but usually) the *best* answer is to `unask the
question':
You should be using a hash, not an array.
I wish I had a convenient term for this kind of mistake. The general
case is:
Someone wants to accomplish task Y.
They determine that a way to accomplish Y is to use facility X.
There is a sub-task of Y, say Z, for which X is ill-suited.
They come into the group and ask `how can I use X to accomplish Z?''
This is a problem for people here trying to answer the real question,
which is:
How can I accomplish Y?
But nobody can answer this question because the querent never
mentioned Y at all, and so nobody knows that the real goal is to
accomplish Y. Instead, they are likely to get a long list of more or
less hacky ways to use X to accomplish Z, which is unfortunate.
A more experienced programmer would not have chosen to use X in the
first place. A more experienced programmer would have determined that
W, not X, was the appropriate facility for accomplishing task Y.
I like to try to guess Y, becayse I often feel that the best advice I
can give is `use W instead of X', and that the world is full of other
people who will suggest the hacky workarounds. Guessing Y is very
diifficult and error-prone. Worse, it's personally risky. Even when
I am right, people may suspect that I'm being facetious. (``The guy
asked a perfectly clear question; why didn't you answer it?'') When
I'm wrong, it's even worse, because I can't defend myself against
charges of facetiousness by pointing out that my advice was good.
Of course, the environment we have here where people do make facetious
answers is conducive to that sort of misunderstanding. I wish people
wouldn't do that, because it makes the environment distrustful, and
the risky answers that I like to give are unsafe in such a distrustful
environment.
Mark-Jason Dominus
In article <fl_aggie-240...@aggie.coaps.fsu.edu>,
I R A Aggie <fl_a...@thepentagon.com> wrote:
>Repost, time..and yes, Olga, there *are* stupid questions.
Since I wrote that, I've found a few more. Right now the #1 on my
shit list are the ones that invent some new syntax out of whole cloth,
and then are puzzled when it doesn't work.
Why doesn't %h{@list} work?
Why doesn't ('foo', ('bar', 'baz')) work?
Why doesn't *#$*NJK@DN(D@HC work?
And gosh, it sure is hard not to be sarcastic here:
``Because it's a syntax error.''
``Because this is Perl, not Lisp.''
``Because the computer can't read your mind.
Guess what? We can't read your mind EITHER.''
``But it *does* work. It just doesn't do what you wanted.
There is a difference, you know.''
``If your problem is how to keep the computer from exploding
when you do that, be sure to call the frobnitz() function.''
I think it must be something about the phrasing that gets me in the
sarcasm gland.
It's so easy to fix these! The maxim here is
CARDINAL RULE OF REPORTING TECHNICAL PROBLEMS:
Never, never, never, never, never say `doesn't work'.
Never.
PROPER PROPHYLAXIS:
Just say ``I wanted X, but it does Y. How do I get X?''
By just including some tiny hint about X, you turn a stupid question
into an intelligent one.
Here's an example from a couple of weeks ago:
>Why does this:
>
> while ( ($k, $v) = each $this->{'stopped_content'}->{} ){
> print $v;
> }
>not run?
Answer: ``Because it's a syntax error.''
Actually, the author here did do the right thing. The original text was:
>Why does this work:
>
> foreach $key (@keys){
> print $this->{'stopped_content'}->{$key};
> }
>But this:
>
> while ( ($k, $v) = each $this->{'stopped_content'}->{} ){
> print $v;
> }
>does not run:
And then the answer becomes ``You should have used
%{$this->{'stopped_content'}}''. See the difference here? One
question can be answered; the other can't.
Here's another recent one:
>i get errors when i try:
>/BOB/d;
Answer: ``Yes, that's what's supposed to happen.''
I am happy to report that the original author did actually include X:
>i get errors when i try:
>/BOB/d;
>trying to delete all BOBs from my file
The answer is now clear: ``Use `print unless /BOB/...' blah blah or
see perlfaq5 `How do I delete a line in a file' ''
I don't have many examples where the author really blew it, because I
try not to answer those questions. I figure that even if I don't,
someone else will come along and say ``BECAUSE YOU CAN'T JUST MAKE
SHIT UP AND EXPECT THE COMPUTER TO MAGICALLY KNOW WHAT YOU MEAN,
RETARDO!''. And even if nobody does cme along and say this, that's
not a bad thing.
Well, here's one I was able to dig up from last month:
Xxxx Xxxxxx wrote:
> I've written a routine to get the file size of each file within a
> specific directory.
> however, it only works on particular files. There doesn't seem to
> be a pattern either. I'm using NT as a platform.
> Any suggestions ?
Dear Xxxx,
Perhaps your veeblefitzer is clogged.
Jonathan Feinberg
m...@op.net (Mark-Jason Dominus) suggests:
> YOU CAN'T JUST MAKE SHIT UP AND EXPECT THE COMPUTER TO MAGICALLY
> KNOW WHAT YOU MEAN, RETARDO!
Or, as we say in c.l.p.m., YCJMSUAETCTMKWYMR. Has a nice ring to it,
somewhat like TMTOWTDI, only bigger. Say along with me,
"Yik-Jim-Su-Eyuhtick-Tim-Kwimmer"
--
Jonathan Feinberg j...@pobox.com Sunny Brooklyn, NY
http://pobox.com/~jdf/
Tushar Samant
bir...@my-dejanews.com writes:
>[snipped away - an outstanding effort and tremendous amount of caring]
And a prodigious amount of verbosity. No MJD-style elaborate
digressive discursion can withstand more than 3 reposts. Axe
it down to a third its size and post it 4 times a year or
something. Not to play down the effort or caring -- but way
too long.
Bob Trieger
Jonathan Feinberg <j...@pobox.com> wrote:
-> m...@op.net (Mark-Jason Dominus) suggests:
->
-> > YOU CAN'T JUST MAKE SHIT UP AND EXPECT THE COMPUTER TO MAGICALLY
-> > KNOW WHAT YOU MEAN, RETARDO!
->
-> Or, as we say in c.l.p.m., YCJMSUAETCTMKWYMR. Has a nice ring to it,
-> somewhat like TMTOWTDI, only bigger. Say along with me,
->
-> "Yik-Jim-Su-Eyuhtick-Tim-Kwimmer"
I love it. I may even name my first child "Yik-Jim-Su-Eyuhtick-Tim-Kwimmer".
Bob Trieger
sowm...@juicepigs.com
" Cost a spammer some cash: Call 1-800-286-0591
and let the jerk that answers know that his
toll free number was sent as spam. "
Eric Bohlman
Mark-Jason Dominus <m...@op.net> wrote:
: I wish I had a convenient term for this kind of mistake. The general
: case is:
: Someone wants to accomplish task Y.
: They determine that a way to accomplish Y is to use facility X.
: There is a sub-task of Y, say Z, for which X is ill-suited.
: They come into the group and ask `how can I use X to accomplish Z?''
: This is a problem for people here trying to answer the real question,
: which is:
: How can I accomplish Y?
: But nobody can answer this question because the querent never
: mentioned Y at all, and so nobody knows that the real goal is to
: accomplish Y. Instead, they are likely to get a long list of more or
: less hacky ways to use X to accomplish Z, which is unfortunate.
I think the term you're looking for is "premature closure"; the poster
has decided on a solution without having completely specified the
problem. Diane Wilson, who sometimes hangs around in
comp.infosystems.www.authoring.html, came up with "solutions as
requirements" though that usually refers to a similar mistake at a
higher, less detailed, level.
If you can tolerate a more verbose phrase, I'd suggest that "trying to
fit the task to a chosen set of tools, rather than choosing the tooset
based on the task" would be a good description.
F.Quednau
Eric Bohlman wrote:
>
> If you can tolerate a more verbose phrase, I'd suggest that "trying to
> fit the task to a chosen set of tools, rather than choosing the tooset
> based on the task" would be a good description.
Fits the shoe. And that is because a beginner has got a restricted set of the
toolbox. Therefore a beginner tends to make its choice of tools first, and then
tries to accomplish the task with that tool, even if it makes his/her life a lot
harder. A good suggestion would be to just read, simply read a book like
'Programming Perl'. Even if you don't understand quite a few things, just flick
through, so that you at least know if there might be some other tool.
F.Quednau
Jonathan Feinberg wrote:
> > YOU CAN'T JUST MAKE SHIT UP AND EXPECT THE COMPUTER TO MAGICALLY
YCJMSUAETCTMKWYMR => YC-JM-SU-AETC-TM-KWYMR
> "Yik-Jim-Su-Eyuhtick-Tim-Kwimmer"
message has been duly filed for later reference. The constant struggle to keep
up with weird jargon. Ts, I don't know...
I R A Aggie
In article <6n6u91$k9q$1...@ligarius.ultra.net>, sowm...@juicepigs.com (Bob
Trieger) wrote:
+ Jonathan Feinberg <j...@pobox.com> wrote:
+ -> "Yik-Jim-Su-Eyuhtick-Tim-Kwimmer"
+ I love it. I may even name my first child "Yik-Jim-Su-Eyuhtick-Tim-Kwimmer".
I believe that would be considered a form of child abuse.
James
I R A Aggie
In article <6n67hm$7gb$1...@monet.op.net>, m...@op.net (Mark-Jason Dominus) wrote:
+ A less abominable example of this that comes up all the time is
+
+ I have an array of strings. How do I check whether the array
+ contains a certain string?
+
+ Usually (not always, but usually) the *best* answer is to `unask the
+ question':
+
+ You should be using a hash, not an array.
+ I wish I had a convenient term for this kind of mistake.
Call it 'Hammer-Nails' as in 'When all you have is a hammer, before long
all your problems start looking like nails'.
James
Mark-Jason Dominus
In article <ebohlmanE...@netcom.com>,
Eric Bohlman <eboh...@netcom.com> wrote:
>I think the term you're looking for is "premature closure";
Wunderbar. Thanks!
>If you can tolerate a more verbose phrase, I'd suggest that "trying to
>fit the task to a chosen set of tools, rather than choosing the tooset
>based on the task" would be a good description.
We can abbreviate this to `Maslowfying'.
Mark-Jason Dominus
In article <6n81lk$sbt$1...@nnrp1.dejanews.com>, <bir...@my-dejanews.com> wrote:
>I think that this autopost is designed to make clear to a poster,
>who got a sarcastic response to his question, why that happened.
No thanks. I don't want anything I wrote to be used to justify
rudeness and sarcasm.
Actually, one reason I've never reposted this article myself is that
the problem it addresses doesn't really come up very often. The
inspiration for it was that guy who wanted to use Perl to collect
email addresses.
It's fun, and people seem to like it, but I don't think it would be
very helpful.
Martin Gregory
bir...@my-dejanews.com writes:
> In article <6n769g$q...@tekka.wwa.com>,
> The autopost is not designed for other people. They can skip it.
> The subject line should be more clear, IMHO.
>
> For example: SOME QUESTIONS CAUSE SARCASTIC ANSWERS. WHY ?
EXCELLENT idea. Is the right person listening, who can make this
change?
Martin.
Teflon
>I love it. I may even name my first child
"Yik-Jim-Su-Eyuhtick-Tim-Kwimmer".
People like you should not be allowed to have children. In most countries
they sterilize retards to prevent unwanted children.
Bob Trieger wrote in message <6n6u91$k9q$1...@ligarius.ultra.net>...
>Jonathan Feinberg <j...@pobox.com> wrote:
>-> m...@op.net (Mark-Jason Dominus) suggests:
>->
>-> > YOU CAN'T JUST MAKE SHIT UP AND EXPECT THE COMPUTER TO MAGICALLY
>-> > KNOW WHAT YOU MEAN, RETARDO!
>->
>-> Or, as we say in c.l.p.m., YCJMSUAETCTMKWYMR. Has a nice ring to it,
>-> somewhat like TMTOWTDI, only bigger. Say along with me,
>->
>-> "Yik-Jim-Su-Eyuhtick-Tim-Kwimmer"
>
>I love it. I may even name my first child
"Yik-Jim-Su-Eyuhtick-Tim-Kwimmer".
>
>
Bob Trieger
"Teflon" <in...@demobuilder.com> wrote:
-> >I love it. I may even name my first child
-> "Yik-Jim-Su-Eyuhtick-Tim-Kwimmer".
->
-> People like you should not be allowed to have children. In most countries
-> they sterilize retards to prevent unwanted children.
->
I've got no rebut, just wanted a chance to post your address without the
NOSPAM in there so the big bad spam monsters will get you. :)