I had someone give me the answer that I asked, and then said, hey why don't you do it this way, and proceeded to give an example. It was infinitely better, and so I went with it.

However, should his way not have been good for reasons that he could not know (due to other issues not in the original post), I still had the answer to my original question.

However, 'why don't you just use a hash' is not always informative, because maybe the OP (me in this case) doesn't know how to use a hash to solve their particular problem.

I have to agree here. The "Why did you do it that way?" question alone is very irritating. But, when the question is followed by someone's idea of faster / smarter / better, it provides insight to a solution that may be more than the original intent.

I've had people answer some of my questions with little more than the "Why do you want to do that?", and I realized that they have their own way of thinking, but didn't want to share it. And simply saying, "Don't use that, use this instead", without giving an example of usage is little more than taking a tool away, and replacing it with a different tool that the person hasn't a clue how to use. They still won't have a good answer, and they are likely to be more confused than when they started.

Note that Dominus grapples with this same question in Why it's stupid to `use a variable as a variable name' (Part 1). He knows that symbolic refs are bad, so when a question comes up about them, should he say so and have people jump on him (just answer the question!), or should he just go on and give the answer and have a completely seperate group of people jump on him (you know this is bad, so why didn't you say so?!!)?

The answer can usually be determined by the context of the question. You may pick up hints that the question came from an experianced coder, either by things said in the post or past experiance. If so, it's probably best to just answer it and let them deal with any consequences.

OTOH, imagine a SoPW like this:

I NEED HELP BUGGING CGI. I TRY GETTING PARAMS FROM CGI

require CGI 'standard'
for $i (Vars()) {
    $$i = param($i);
}
[download]

BUT IT DONT WORK NEED HELP PLEASE THANKS

If you answer that question without showing why its bad, be prepared to meet my clue-by-four :)

Says hardburn:

Note that Dominus grapples with this same question in Why it's stupid to `use a variable as a variable name' (Part 1).

I agree that I was grappling with the same isue. However, I think your characterization of my example is inaccurate. You said:

He knows that symbolic refs are bad, so when a question comes up about them, should he say so and have people jump on him (just answer the question!), or should he just go on and give the answer and have a completely seperate group of people jump on him (you know this is bad, so why didn't you say so?!!)?

and I think if you will take the time to reread my article, you wil find that my actual concern was rather different from what you said.

At least, I hope you are able to see the difference.

--
Mark Dominus
Perl Paraphernalia

What does that mean? First, if possible, I'll answer the question (or request additional info so that the question can be answered). Along the way, I will try to point out relevant documentation that might assist the person who asked the question in digging deeper into the subject, and in seeing how and why the answer provided works. If I see a reason, I may also point out other issues in the OP's code that may not have come up in the question, but that are likely to either come up later, or that might simply be done in a way that is more in keeping with Perlish 'best practices'. And finally, if the question sparks an interest in me, I may even propose a couple other alternatives, or dig in deeper into a discussion on a particular aspect of the project the OP is working on.

Sometimes that means the person who asks a simple question gets a simple answer plus a heap of "Too much information." But here's why I often take that route: The person who is asking a question, and who only wants the concise answer and nothing more, probably isn't really concerned with learning Perl. His motivation may be to get a project done, turn the homework in, get a pre-made script working, etc., and then move on and never look at Perl again. But I'm not going to pre-judge the level of interest this person has for him. While reality may be that the person asking the question just sifts through what I have to say and plucks out a cut-n-paste answer, the hope is that this is someone, like myself, who has a desire to dig into the hows, whys, and what-ifs. And for that person, I am motivated to go the extra mile.

Take a salesperson. When a customer walks into a store, if the salesperson sizes him up and decides he can probably only afford the $50 DVD player, that salesperson has done himself and his customer a disservice if the customer, in fact, would be happier with, and can afford, the $300 DVD player.

If I size someone up who is asking a question and decide at the outset this is someone who isn't going to want anything beyond the most concise answer, I may be jipping that person out of an opportunity to learn, if in fact, that is his goal. Furthermore, I'm robbing myself of another opportunity to meditate on a subject, possibly learning something new myself in the process. And equally important, I may be robbing others the opportunity to learn something; for every inquisitor and respondant, there is an army of lurkers.

I have benefitted many times from those people in this community who have taken the approach of giving more information instead of less. If people just answered the damn question and moved on, this place would get boring, and I would have stopped learning here practically as quickly as I started. It is the deeper explorations, the other points of view, the "by the way, did you consider this?", and the "you may want to read xxxx" types of answers that make this place so interesting, so educational, and so alluring.

So if all someone wants is the quick answer, too bad. I don't care if someone is going to jump on me for showing how to use a symbolic reference, while at the same time explaining some of the ramifications. Because for every person who just wants the quick answer, there are (at least in my hopes) many who are glad to learn from the in-depth answers.

• "I need to get data from an Excel spreadsheet into a form that allows the user to choose which FOO to get the BAR info about."
• "How do I modify the variable named in another variable?"

Programming (and life, for that matter) is about thinking. It's about knowing what question to ask. Charlie Brown once quoted someone I don't know, saying "The more I learn, the more I know how much I don't know." I take that to mean "The more I learn, the more I discover what is knowable."

Douglas Adams puts it another way. In his Hitchiker's Guide series, he describes a civilization that took 100 generations to build a machine that gave them the answer to the Ultimate Question. It then took them 1000 generations to build the machine that gave them the question for the Ultimate Answer. (The second machine was the Earth, but that's another story, better told by the white mice.)

My rationale for being in the Question-Further camp is this - I'd prefer to teach you how to fish than give you a fishstick. Most answers need context. (Which, coincedentally, is how all education works - by expanding context. You need to be able to hook in what you're learning to what you already know. That's why geometry is taught before limits is taught before calculus. You can't hook calculus onto anything without limits, and on down to geometry. It's also why Peano's Postulates aren't taught until college. Even though it's just about the whole numbers, you can't understand them without a concept of spaces.)

If you ask about modifying a variable named in another variable, I'm going to explain what the heck it is you're really asking about. I'm going to point you in the direction of basic knowledge (hashes). I'm going to point you in the direction of structured programming (which it seems most Perl coders have a serious aversion to, kinda like bathing for Magic players). I'm going to attempt to tutor you and educate you. After all of that, if you still want to know how, you'll already know. I mean, if symbolic references were all bad, then why would Perl allow them? Why would many of the modules we use every day use them? Why would people like me write code that's used in production that makes use of them?

if symbolic references were all bad, then why would Perl allow them?

I think I just found something to stick in my sig :-)

duff

Because we need there to be MTOWT Shoot Your Foot Off. One of the other Extreme Foot-removal devices is one of the bugs noted in perldoc perl, namely that -w is not mandatory.

"Arrogance is bad mmkay?"

I agree that arrogance is bad .. but a helpful attitude can look like arrogance to a closed mind.

I see three possible responses to a technical question:

1. Here's the answer.
2. Why are you doing it that way?
3. If you do it that way, you'll likely encounter the following problems ..
Any or all of these might be in an answer. #1 should always be present .. #2 probes gently, to see if the questioner understands some of the underlying issues at work, and #3 is more direct, possibly lecturing.

I understand people don't like to be lectured, but I suppose some of the bretheren come off like that. I bet if merlyn were mechanical, he'd have deep grooves in his eyeballs from the number of times that he's rolled his eyes when someone asks about parsing CGI parameters themselves (or anything that deserves the response "Why re-invent the wheel?"). It's not surprising that some responses from this community go straight to #3. This is bad?

Of course, if you come to The Monastery seeking wisdom (or even knowledge), don't be surprised when someone tries to teach you -- even if you don't realize it at the time.

--t. alex
Life is short: get busy!

Well, everything has its down side and limitation. When I agree that some time one probably should question the question, there is really no point to push that too much. If everybody started to question the question instead of answering it, very soon, nobody will come here to ask questions any more.

You don't assume that the person who questions the question is right. It all depends on. The answers to some questions are very obvious, but most of the time, it is not that simple, and the OP usually have a better understanding of the situation than we do, they are just stuck with certain language particular aspects.

Leave this to each monk that answers the particular question, to determine what to do. The monks here are talented, and let's don't worry too much to guide them what they should do.

As I see it, offering different approaches are very valuable, not only to the OP, but to all monks, and potential Super Searchers. If there are already replies on the OP's question, I think you're allowed to skip giving the specific answer to the question, and jump straight to the alternative way. Heck, we are discussing Perl, so there must be at least one other way to do something (be it better or worse). I think you could even add something like "[monk] suggested yada yada yada, but you can also do it like this ...", but if the "right" solution is already explained three times, because the monks all started typing right off, I think you can even skip that.

Some thing I'd like to draw the attention to, is the use of non-Perl solutions. Is that acceptable? Take for example this node about merging three files. This can easilly be done by the use of nl, join and paste (GNU tools), as I described in my reply. It produces the output the OP wanted and in this specific case, I think the OP only wanted to see the result. My reply started out with 2 downvotes and is currently at 2 plusvotes (so, 4 plus votes really). Is this type of replying thought of as added bonus (CombatSquirrel already posted his Perl solution), or is it redundant, and shouldn't it be posted at all? I am not sure.

--
b10m

Absolutely. Sometimes the best answer is "You *could* solve that with Perl, but there's an even better answer already available at the Linux command line!"

That's perfectly valid. Why use a chain saw when a butter knife will do?

--t. alex
Life is short: get busy!

ps Because a chain saw is more fun? Yes, I saw that one coming. :)

That's terrific value, isn't it?

Example: some time ago, someone asked help with processing command line arguments. He had posted some code that looped over @ARGV, but he didn't get the results he expected. He got several answers that he should be using one of the Getopt:: modules. "Terrific value"? No. The answer "Just use a module" didn't teach *anything* to the poster. Sure, it might have solved the immediate problem, but it's like a doctor prescribing pain-killers for a broken bone. It takes away the pain - but it doesn't cure the cause. In this case, the OP had an off-by-one error in processing the array. If people had taken the time of looking at the code instead of pointing to a module, the OP had learned something.

I usually try to avoid answering the meta question. Instead, I might answer the question with another question, trying to make the OP think what (s)he really wants to do.

Abigail