Well for one thing, you don't just get one shot, this is a discussion. If you ask as best you know how and someone answers a different question than the one you want answered, you continue the discussion by saying, no that's not what I meant, what I meant is more like ... and if the answer to that one isn't right, you ask a third time. And perhaps from that process of asking not-quite-the-right-question you learn how people are likely to interpret what you are asking so that the next time you ask something, you take how they are likely to interpret it into account and skip a few of the steps.

Either you know what you want to ask, in which case, you just ask it and it's no longer within your control how people answer it, or else you don't know what you want to ask, in which case you make as good an attempt as possible and you take the replies (even the wrong ones) as stepping stones to the right question.

update:I wrote the above on general priciples, then I went and looked at one of your recent questions (464621) and it turns out to be a perfect example of what I meant. Instead of clarifying what you meant or telling us how the supplied answers were insufficient or off-base, you simply gave up. I recommend that you look back over that question and the responses to it and continue the discussion, tell us why the answers didn't suit you so we can begin to guess what your question was really about. It doesn't really matter whether the miscommunication was on your part in how you asked the question or in the answerers part in how they (mis)interpreted your question. The point is, there was miscommunication and the only way to solve that is to communicate further.

There are some general tips - use a relevant subject line, be specific, include examples, and so forth. But once you put your question out there, it goes through the filter of an individual. Most of us end up getting good at a very narrow range of solutions - whose jobs give much time to really understand things that your company isn't using? Most of us only learn a few new things at once.

And that's part of the point of why we ask on places like this.

So, the effect is that your question gets filtered through everyone's personal query of "Can I solve this using the tools I have?" And if people can, or sort of can, or can if you squint at the problem set a little, they tend to post. Sometimes, their view into the problem is the one you want (and sometimes not the view you expected to want). More often, someone else's toolset is too far from your own to be useful. That's the nature of a vast collaborative site without the shared context of, say, an engineering department at a given company.

Factually wrong answers are another problem, but hard to solve - people probably aren't trying to be wrong. Hopefully someone else will come along before you fall down a rabbit hole from the misinformation, and both of you will learn something.

I have sometimes received replies that missed what I was asking, but hey, it's free advice. One can't expect people to put as much effort into their answers as one puts into one's questions. After all, one is getting something for free.

I have also discovered this: very often, in the process of making my question as crystal clear and unambiguous as possible, I end up thinking up the answer myself!

• Posting working (or almost working) code is a huge plus. It amazes me how often the monks have to request code from OPs.
• Posting pseudo-code can be very helpful sometimes, because it allows one to express algorithmic ideas more precisely than does prose, without requiring a working implementation.
• If the question is about how to process some input, then posting both some sample input and the corresponding desired output is also a huge plus.
• If you want to understand how something is done, and not just get it done, then say so, so that you don't get pelted with pointers to CPAN that leave you none the wiser.
• Learn to ask by watching how others ask. Over time you will find that some people ask questions very well, and get good answers right away. Learn from them. Study the well-posed questions and try to figure out what makes work.
• Realize that asking questions well often very hard, simply because when you are immersed in a problem it is nearly impossible to know how to describe it fully to anyone else. This means that, try as you may, there's a good chance you won't get it right. Luckily, in PM replies arrive quickly, plus you can update your posts, which means that you can clear up any misunderstandings that you detect from the first reply or two in an update.

I'd add two caveats to your request for code. Please format your code readably, and please post the smallest amount of code that demonstrates the problem. It is far less work to read 20 lines than 200. I have found, when doing this, that I have found precisely where the problem is, found the solution in the docs, and been able to save pleas to the community for when they are needed. I do leave strict in, though - everyone who leaves it out seems to get advised to put it in, so I do.

Regards,

John Davies

For example, people very often say that they want to do something without using CPAN modules. When questioned they usually say that it is because they don't have root access and can't install them. That is absurd! Not only are there ways of installing modules in directories that you can access, but even the worst case scenario, if you are able to copy and paste code from a perlmonks.org node, you can also copy it from CPAN (of course, I'd recomment trying to install it properly first). (Licensing issues may be more complicated, though.)

The same may also apply to databases. If you want to write hundreds of lines of code to do something that you could do with a few lines and a free database, I'll be more motivated to reply if at least you say why you don't want a database. Even if it's just because it was a homework problem that stated "do this without using a database".

  use Term::ReadKey;
  ReadMode 4;
  system("wget http://fetchsite.com?q=the-letter-$_")
    while (defined $_ = ReadKey());
[download]

Thanks! :) That was exactly what I was looking for, PM is great!

1. If it's not a trade secret, explain what the problem you're trying to solve really is, and why you're trying to solve it in the first place. If you're trying to move the moon closer to the sun so that it will reflect more light, and let you read Perlmonks at night, a fellow monk might point out that a nightlight is a simpler solution. :-)
2. Explain what options you're not willing to explore, and why. "The boss hates Mysql, so we can't use it", "Postgress support for mythic widget X is still in beta, so I don't want to use it", "I only understand SQL Server, so that's what I want to use", etc. This helps fellow monks understand why you're not interested in the "buzz-of-the-week" technology; otherwise, why shouldn't suggest you go with "popular wisdom"? In a sense, that's what you're asking for when you ask a large group of people a question.
3. Repeat yourself. Write the main point of your article in the introduction, explain it in detail, and recap the main thrust of the question in the summary. That way, you're less likely to get an answer to a technical side-avenue of your problem, while the main point remains unsolved.
4. Learn to evaluate responses. Monks abilities vary widely; and this includes the self-assessment ability as well. They may think answers are right that aren't, or misread your question entirely, because they know the answer to the simpler interpretation. Be patient with these monks: they're usually not doing it on purpose, they just make mistakes, like all of us. Remember, you're not paying these people to help you: they're volunteering their time, and giving their best effort, and even the best people slip up now and then.
5. Explain the options you've tried, and why they didn't do what you want. People are more willing to help when they know you've tried. If you're struggling with how to code something, post some sample code that demonstrates the problem, with sample inputs, and expected outputs. If you're struggling with something more abstract, explain the lines of reasoning you've tried, and what you liked/didn't like about each.
6. Communicate with people. Thank fellow monks for responses; even if they're wrong, they still tried to help you out. Friendliness helps build our community and encourages people to post. If someone has lost track of the original idea, polite follow-ups to clarify why certain suggestions don't work, and what you'ld really like to see happen.
7. Don't expect miracles. This is a free site: and sometimes, the expert who knows the perfect answer to your question might be sick, tired, or on vacation. We've got a lot of talented people here, but they get busy. Be patient, and hope for the best.

EDIT: Why does my post have these squiggles at the start? I didn't put them there. Did the post table get corrupted?

Programmers constantly deal with two fundamental questions: "What?" and "How?". "What?" describes a result.. the output from some process. "How?" describes the process itself.

Start from there.

When you get answers of the "use {solution X}" variety, it's reasonably certain your question began with the word "How", and that you didn't put any constraints on the set of tools you consider acceptable for solving the problem. You've asked people to describe a process that will produce some result, and that's what they've done.

When you get questions that solve the wrong problem, it's a sign that your "What?" might not have been clear. You probably left the result itself open to interpretation, and someone interpreted the terms differently than you did.

(As an aside, "How?" and "What?" are analytical questions. They encourage people to break something down into smaller pieces. "Why?" is an abstracting question. It encourages people to wrap lots of details up in a nice, tidy summary. I once had a moment of Zen perfection when a girlfriend grumpily asked, "Why do you always feel like you have to explain things?")

To make matters more fun, the question "What?" has at least two meaningful layers of abstraction in programming. The low-level abstraction is a dataflow diagram.. What do you put into the program, and what comes out? The high-level abstraction is a use case analysis.. What problem does the user have that the program is supposed to solve?

Then there's a certain amount of "How?" just in turning the use cases into a dataflow.

I once made a fairly healthy chunk of cash consulting to a company which was having major performance issues with a database-backed program, for instance. They needed to be able to handle 100K+ hits in an 8-hour period, but the program they had bottlenecked at about 12 hits per second. They hired me to optimize their table structure, tweak SQL queries, and so on. I spent 15 minutes profiling the bottleneck, discovered that most of the bottleneck was network and database latency, and wrote a replacement storage system using flat-files that profiled 200x faster. The use-case was that they wanted to store a user's information. Their implicit "How?" was that the data should be stored in a database on a remote server, under conditions where the connection latency amortized very badly.

So, if your question doesn't have:

1. A use-case statement (what good does the user get out of this?),
2. Some very basic and abstract dataflow (broadly speaking, what goes in and what comes out?),
3. Some constraints on the toolset used to solve the problem,
4. And a rough list of performance priorities (speed trumps readability, or vice versa.. lowest possible maintenance comes first.. must offer flexibility for future growth)

then there are just too many free variables to expect the discussion to be focused.

More to the point, if you can't slot your question into one of these pigeonholes:

• Am I asking for information about use cases in general?
• Am I asking about basic assumptions that turn a use case into a dataflow?
• Am I asking for ways to implement a given dataflow?
• Am I asking how a given solution (or set of solutions) meets certain performance criteria?

then it's probably a good idea to sit back and figure out exactly what kind of question you're trying to ask.

I search for answers here. And the questions that get the best answers, I try to pay attention to how they are phrased.

Outside of that relax and converse, a single question and a series of answers is not as rewarding as a discussion with one question that raises many.

Yes, but such flow of conversation is fine for mailing list, or IRC channel, but on perlmonks it makes it hard to find relevant data, ie, with mailing list, when subject of discussion changes, you can express that in the SUBJECT.

With PM you have to rely on search function.

One cannot change the SUBJECT, but one is free to change the title of the node.


holli, /regexed monk/