Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: Writing answers for newbie questions

by Abigail (Deacon)
on Jun 27, 2001 at 03:38 UTC ( #91783=note: print w/replies, xml ) Need Help??

in reply to Writing answers for newbie questions

I disagree. I'm not going to explain every function or module I use. Then it takes me hours to answer some questions. That's what the TFM is for. If you ask a question, get an answer which uses function foo you don't know about, is it too much to ask to spend a few seconds typing perldoc -f foo in a different window? Should authors really cut and paste the documentation for every question they answer, just because the asker of the question might be a newbie? (How do you know? Do they smell different?)

As for

$string =~ s/\s+/ /g;
I fail to see what the problem is with that. If there are parts in the code the reader doesn't understand, (s)he can look it up. Now the excuse of "I don't know what to look up" doesn't hold.

One last thing. You mentioned the infamous baby code. Is there an official piece of documentation that lists what's part of baby code and what isn't? Because only then, one can answer in baby code. Or does every one has his/her own baby code, which just happens to be the set of constructs the person knows about? Perhaps everyone signing on for Perlmonks could fill out a form with 2500 tickboxes, marking all the commands and constructs they know about, making that their own private baby code. Then people can study those sets and adjust their answer. Keep in mind that people are learning, so you would have to force them to update their pages at least weekly, but preferably daily.

BTW, don't you think showing people constructs or functions they haven't heard of before is the best way to get them out of the baby code stage, and into the world of full Perl enjoyment?

-- Abigail

Replies are listed 'Best First'.
Re: Re: Writing answers for newbie questions
by footpad (Abbot) on Jun 27, 2001 at 09:15 UTC

    It is written in the Third book of Camel:

    Most important, you don't have to know everything there is to know about Perl before you can write useful programs. You can learn Perl "small end first." You can program in Perl Baby-Talk, and we promise not to laugh. Or more precisely, we promise not to laugh any more than we'd giggle at a child's creative way of putting things...Any level of language proficiency is acceptable in Perl culture. We won't send the language police after you. A Perl script is "correct" if it gets the job done before your boss fires you.
    --Preface, pp xix-xx. (emphasis added).

    No one expects you to "dumb down" your experience or writing style to Baby Perl, however, I've found that the wisest of comunicators understands, at least in part, the amount of "TRVTH" their audience can take in a given session. This is, I think, part of what [merlyn|Larry|Tom|whoever](*) was getting at when he wrote the above.

    (Note, that's an assumption, one based solely on his writings here and elsewhere. If it's a bad one, then please feel free to insert the proper author's name. The point being the same...whoever originally keyed those words understood that Perl is a language with many levels and many subtleties...and that everyone must learn to crawl before they can leap tall idioms in a single bound...yes, even Clerk Kant.)

    I agree that we should be willing to challenge people as needed and as appropriate...however, is it not true that each finds their own path along the Perl Way? Is it not true that some may need to work their way through less than ideal solutions before they arrive at the "best" ones? Also, who's to say that any single solution is precisely the exact answer that's best for every need? Each problem is unique, as is each poster. Some approaches are more effective than others, certainly...however, I believe that part of Perl's flexibility stems from the fact that someone understood that it was better to provide flexible interfaces and tools, rather than rigid, dogmatic ones (ala C++, imho).

    Personally, I have no problems asking for clarifications when I don't get it. However, not everyone has that much of a spine. Some would take an RTFM screed far more pointedly (and personally) than others...and that's (in part) why I think the Monastery has a bit of a bad rep regarding the treatment of newcomers.

    Finally, as someone who has spent hours composing replies in other fora...yes, it sometimes takes that long to hazard a good guess. However, when you do it correctly, you gain more than the "win" of being also help someone else see the light. In addition, you also help those that aren't directly involved in the conversation..yeah, the lurkers. Your online words have a broader audience than your RL-words.

    No one doubts your skill and we're certainly now asking for a line-by-line breakdown. However, when you're doing something that might seem tricky to a new person, it doesn't seem unreasonable to include HREF links, man page references, or other Resources for further consideration. Signposts, if you will, into the land of imagination...the Twi...Oh, wait...sorry. Wrong intro.


    (*) - Update: I've been told via a private /msg that passage was originally written by Larry himself. Can anyone confirm that?

      I am aware of the quote in the third Camel. However, said quote only mentions the existance of Baby Perl. It doesn't define what Baby Perl is. In fact, it strongly suggests everyone has his/her own Baby Perl.

      And that's just fine. However, in no way this quote implies one should be expected to be addressed in Baby Perl. There isn't a single book written in Baby Perl. No manual page in the Perl distribution talks in Baby Perl. Yet many books are aimed at beginners, and so are tutorials in the main distribution.

      Here's an experiment. Get married. Get twins. Call them Angela and Bobby. Separate them. Expose Bobby only to language at his own level. "Dadadadadada" when he's a baby, and one syllable, one word sentences when he's a toddler. Only use words he already knows. To Angela on the other hand, you only talk normally. Normal sentences, with verbs, subjects and objects. On each birthday, compare their linguistic development. Describe the differences. Motive your answer.

      And even if you remain convinced you should talk Baby Perl to people asking questions, you still have a practical problem. You will not know what they know. Will you not use a substitution in an answer because you think they don't know substitutions? What about hashes? grep? strict? -w? Perhaps they don't know open has a useful return value. Should you ignore the return value in your answer? Not use Not use pack? Not use substr?

      -- Abigail

Re (tilly) 2: Writing answers for newbie questions
by tilly (Archbishop) on Jun 27, 2001 at 13:35 UTC
    This is a request.

    If you see a question whose form and/or content indicates an extreme lack of clue, then either do not answer or else take the time to explain what you are using. Saying politely that the documentation is helpful is useful but insufficient. For the truly clueless it is useful to give an explanation of how to navigate documentation.

    Here is an example of what I mean by an explanation of how to navigate documentation.

    Also note that just inspiring someone to learn more does not mean that they know how to do that. For instance you offer an example of a substitution which most Perl programmers should be able to understand. But if someone does not, then they problably do not know about perldoc, do not know what a regular expression is, and will have no way to find perlre. So while I would answer a question with that answer, if I got a follow-up question I would be willing to respond with some combination of an explanation, a mention of perlre, a recommendation for the Owl book, and a recommendation for japhy's YAPE::Regex::Explain.

    Furthermore if you can find ways to subtly phrase things in a manner that indicates that you are actively trying to be helpful and impart knowledge, that is always good. For instance rather than just say that someone should have done a search, point to the search engine, say that the search engine is really helpful, and link to the result of a basic search. That passes on the same information but leaves the questioner happier and more likely to follow your advice. I find the small additional energy expenditure more than made up for by the energy savings from less conflict.

    Again, if this sounds like too much work for you, then don't answer that question. Move on to a question that looks like it comes from a more sophisticated user. If the question is basic, it is a safe assumption that someone else will answer it. If there is some subtle mistake that you think people are likely to make, then it is typically most useful for all involved for you to wait for someone to misanswer the question, and then politely correct the bad answer. More than anything you can say, this flags the point as something people can easily get wrong. Plus at least one vocal person is now going to pay attention to your answer and is likely to answer the question correctly the next time.

      For instance you offer an example of a substitution which most Perl programmers should be able to understand. But if someone does not, then they problably do not know about perldoc, do not know what a regular expression is, and will have no way to find perlre

      Neato. So, I guess we should now cut and paste documentation of everything you use in answering a question? After all, of anything you use to answer a question, the person asking might not know about. And since there's no way to tell, (because I don't think anyone here would suggest the person asking needs to do anything more than the minimum, so just telling what said person knows or does not know is out of the question), all you can do is assume the person asking has zero knowledge.

      Is it ok to cut and paste the entire OED in each posting? A person might not know a certain word you use, and it might entirely be possible the person asking doesn't own a dictionary. Hmmm, perhaps the OED isn't enough, and we should also translate the OED to all possible languages - just in the off change the person asking isn't a native English speaker. Oh, and of course we should include pictures as well, perhaps the person can't read either!

      -- Abigail, thinking questions about consulting documentation should be seen as separate questions - which, once answered, could be linked to from for instance the front page.

        You gave an example of an answer, after which people should know what to look up.

        I pointed out legitimate reasons why a beginner would find that answer not helpful, and then proceeded to say that the answer is one I would give, but I would handle possible confusion by being ready with a list of useful references if the follow-up indicated confusion.

        How did you get from that to the insane conclusion that I thought all posts should include the documentation for everything you used in answering the question?

        People with unexpectedly poor backgrounds are like possible tangents in a conversation. They come up every so often, and you handle them with a lazy algorithm. If the person apparently has less background than your first response assumed, you deal with it by politely pointing out appropriate existing answers and tools.

      Hmm, sounds like some macros would be helpful. On the server side, something like [rtfm://super search] could expand into an entire paragraph.
(jeffa) 2Re: Writing answers for newbie questions
by jeffa (Bishop) on Jun 27, 2001 at 08:18 UTC
    Almost. I think a better way of elevating people into the world of full Perl enjoyment is to show them WHY they need that new construct or function. Otherwise, it's just more noise to those that aren't ready to receive higher knowledge.

    Just showing is not really enough. If someone takes a brilliant one-liner and adds it to their program or application without knowing how it works, then that is really just black-box reuse.

    But for God's sake, don't quit doing what you do! I think what cLive ;-) was getting at is we need all kinds of levels of answers. Remember, answers directed at the seeker of wisdom are read by many more potential lurkers, and while you may know the level of the seeker, you cannot know the levels of the unknown lurkers . . .


      Almost. I think a better way of elevating people into the world of full Perl enjoyment is to show them WHY they need that new construct or function. Otherwise, it's just more noise to those that aren't ready to receive higher knowledge.

      How would I know 1) they don't know the contruct(s) I might be using? 2) they aren't ready to receive higher knowledge?

      I refuse to assume people are stupid. Nor do I believe spoon feeding leads to Nirvana. I will keep assuming people are interested enough in Perl that when they see something new, they will do some discovery themselves. I also believes that that is better for the people too - because by doing a little research yourself, you will find more new things, leading to ever more finds when exploring them. That will push the borders of their knowledge much further than spoonfeeding. It keeps Perl much more interesting, and it insults the intelligence of the other people less.

      It's like going on vacation to an unknown city. It's no fun to go their using with a list saying where to turn left and right, which restaurants to visit, what to order, and how much to leave for a tip, than to just hear "that's an interesting city", and then go exploring yourself.

      But then, perhaps I'm just an old gezer who hasn't been dumbed down by television.

      -- Abigail, the television less.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://91783]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2020-11-23 20:32 GMT
Find Nodes?
    Voting Booth?

    No recent polls found