Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Are there questions to basic?

by OzzyOsbourne (Chaplain)
on Oct 11, 2000 at 16:36 UTC ( #36207=perlmeditation: print w/replies, xml ) Need Help??

This is really basic stuff, and you should really grab a book...
You need to re-read the documentation…
Again, read the docs that come with…

While I agree that people should pick up a book to aid in learning Perl, and look through the documentation for answers as their first course of action, the above lines could imply that the question asked was a waste of the posters time (This was a very gentle implication, mind you, as most posters did give answers in the ensuing lines.) I've seen this on a few occasions to prod new users to get users familiar with the docs, but I’m not sure if it is a prod or a provision.

It reminds me of, say, a serf asking a Lord for a shilling. Instead of just handing the shilling over, the Lord must first expound on how rich he is, and how trivial this shilling is to his vast estates, and that the serf could have estates like him if he were smarter and knew how to read, and had some very fashionable tights and a 20 pound medallion…

Or is it more like a Monk saying, “here’s a fish, and there is a stash of fishing rods over behind those rocks for next time…

I prefer to think it is the latter.

I guess what I'm asking is: Are there questions that are too basic? Should a newbie be required to pour over the docs for answers that we can provide in 5 seconds?

I just remember being really green, and not even knowing how to get at the docs to review them. After a couple of big slams about reading the docs, I didn't feel comfortable asking easy questions before spending hours reading the documentation.

I did learn to use the docs, though...

. -OzzyOsbourne, monkaholics anonymous

Replies are listed 'Best First'.
(jcwren) RE: Are there questions to [sic] basic?
by jcwren (Prior) on Oct 11, 2000 at 17:24 UTC
    This is a question I've thought about at different times, and come up with different answers each time. This is my thinking for now.

    Homework: Let's take the case of the person asking to stick the values 1 through 10 into a hash, and print them back out. This clearly reeked of homework. I've decided (for me) that if people really are asking homework questions, they should be slapped. And hard. The point of homework is not to go ask someone else for the answers. I imagine that we all pretty much agree on this.

    Questions: When I looked at my first post, I was asking how to pass named parameters to a subroutine. I wasn't strong on anonymous hashes, and I clearly identified that I had left my trusty Perl CD Bookshelf at home that day, and needed an answer. Without the context, this could be construed as a homework question. I feel if someone qualifies why they're looking for an answer ("I don't know *where* to look", "I have a 2400 modem connection, web searchs are painful", etc), I'm much more tolerant of 'newbie' class questions.

    Formatting, etc: Folks that post without reading the how-to post really bother me. It's like jumping into a newsgroup without reading the FAQ for that group, or reading old messages to get a feel for it. "Oh look, a place to type, let's ask a question" seems to be the method for some people. My favorite pet peeve is "My program doesn't work, how come?" Giving as much information as possible (within reason, of course. Generally, no one cares if you used 'vi' to edit) is a definite incentive to help. Playing "guess what the user really means" is not my pasttime. I don't think that "You suck, provide more information or else." type replies are necessary, but I've seen a number of instances where respondents tried to guess what the poster was asking for. Sometimes right, sometimes wrong, but it shouldn't be necessary.

    CPAN: On the other hand, it took me a little bit to grasp just how comprehensive the Comprehensive Perl Archive Network (CPAN) is. I think many people end up "re-inventing the wheel" because the wheel store is not well advertised. Oh, once you know it's there, that's the first place you head. But CPAN needs to be better advertised for people getting into Perl. Most of the books touch on it, but don't say "You probably don't really need to write that, there's a module already". That should be beaten into peoples heads, not casually tossed out.

    Search engines: In this day and age, I feel that if you don't know how to use a search engine, you shouldn't be on the net. There's dozens, nay, hundreds of questions I could have asked here, but found the answer through Google. And that's not the only search engine. There's Dogpile, Alta Vista, Yahoo, literally dozens of search engines. Not to mention the newsgroups (Oh yea, and jlp, when he's around. He's a pretty handy resource when I'm having a senior moment).

    Now, one of the unfortunate things that Perl suffers from, although admittedly to a lesser degree than Linux itself, is too much information. Nothing like 20,000 people compulsively mirroring information from 3 years ago, that's horribly out of date, with bad links (this is a pet peeve of mine. Search engines need to re-index a *lot* more often). Try searching for 'Perl hash anonymous' in Google. 29,600 hits as of 10/11/2000, 13:22 GMT. Some words are so common that it's hard to find an answer. And relative to the 3rd paragraph, if someome says they've tried the search engines and can't find a helpful answer, then that makes me more inclined to try to help them.

    Finally, there is something we need to keep in mind. This has been mentioned by others, but is well worth repeating. We were all new at something, at one time or another. While we have some *very* experienced people here, we also get a lot of people new to the langauge, and new to programming in general. Before we blow them off with a "This is too obvious" type reply, we need to remember that an answer like that is not beneficial to *anyone*. They can always be directed to resources that will answer their questions, but we don't have to be rude about it.

    And maybe that's (more or less) the bottom line of this ramble. Rather than give an insulting answer (except in the case of homework questions, where that's just plain fun), we can point them towards resources oriented towards their skill levels, whether on site, on 'net, or in print. If we tried to answer every question every 'newbie' asked with a complete answer, we'd have a lot of very large duplicate nodes...


    (And because I can't seem to stop typing this morning, I'll add one more thing. I judge each question to be answered on it's own merit. Sometimes I'll pursue a question because it's an interesting challenge, sometimes because I think a previous poster is wrong, and sometimes because I don't know the answer, and think I should. And sometimes, just sometimes, to be the first to post a reply... (How SlashDot-esq, eh?))

    e-mail jcwren
RE (tilly) 1: Are there questions to basic?
by tilly (Archbishop) on Oct 11, 2000 at 18:06 UTC
    This brings up a related and harder question.

    When someone asks a question, should you answer the question that they asked or the question that you think they should be asking? This applies because often someone asking a question really needs to know how to answer it for themselves rather than the answer to that specific question. But very often people show up saying, "I need to do this, how do I do this" when it is obvious that the fact that they want to do that indicates they should be learning about something else.

    So should you answer the question asked (say how to do a soft reference) or explain why you think they should be thinking about something else? I tend to do the latter but don't really know how to draw the line. Thoughts?

      I always try to look at the context of the question as well. I try to figure out not only what they are trying to do, but why they are doing it as well as how they are doing it. Yes, there is often a strong risk of coming across as pushy, but most people appreciate the "ancillary" help as well as the direct answer to their question. Often times this involves showing another way to do something. The best threads on this site (in my opinion) is where someone asks (or indirectly asks) "How can I do X?" Then many people all contribute different ways of doing it, some perhaps "better", some "faster", but mostly just different. Sometimes the discussion goes far afield from the original question - which is a very good thing, and one of the strengths of the monastery.

      I've been involved in a similar vein of discussion on a completely unrelated forum. I'm more of the inclination to answer the question as asked. But, the matter of interpretation is left to the reader. In other words, if the question is as specific as to state full requirements, then an answer is best given within those conditions. But if no requirements are given, then a good answer will involve the best interpretation.

      This kind of relates to something I learned in my Automata Theory course at school. If the answer isn't readily available, then redefine the question. Since programs should be able to be reduced to mathematical representations, this is perfectly legal as long as the end result was arrived at using valid operations.

      ALL HAIL BRAK!!!

RE: Are there questions to basic?
by KM (Priest) on Oct 11, 2000 at 16:47 UTC
    I guess what I'm asking is: Are there questions that are too basic? Should a newbie be required to pour over the docs for answers that we can provide in 5 seconds?

    I would say absolutely! Getting answers in five seconds isn't a good way of learning. And, if you repeatedly do it, you won't learn anything but how someone else says to do it. It is amazing what you can learn when trying to find a 'simple' answer in the docs. You may be looking up something simple about how to make a coderef, and suddenly get sidetracked into sockets or OO. The path to find an answer contains other answers of unasked questions.

    I just remember being really green, and not even knowing how to get at the docs to review them.

    That may be the real problem. I don't think every person asking a simple question is simply lazy. I think one problem is that they do not know about perldoc, or the wealth of information they can find on the web (tutorials, books, articles, etc...) by default. I think it is our job to point (or prod) people into looking at the docs, even tell them the exact place the answer is, just don't tell them the answer. (this goes for novice-like questions)

    Or is it more like a Monk saying, “here’s a fish, and there is a stash of fishing rods over behind those rocks for next time…

    Well, being a vegetarian I like this better: Give a person a carrot they eat for a day, show them how to grow a garden, they eat for a lifetime.


      I guess what I'm asking is: Are there questions that are too basic? Should a newbie be required to pour over the docs for answers that we can provide in 5 seconds?
      I would say absolutely! Getting answers in five seconds isn't a good way of learning. And, if you repeatedly do it, you won't learn anything but how someone else says to do it.
      Actually, my experience is fundamentally different.

      One of my most enjoyable learning experiences is learning a) a new language, and b) the programming practices and use of an existing code base by sitting among three other programmers and being able to just throw out quick questions, getting answers within seconds.

      I realize that maybe Perlmonks isn't the same thing, but I can say that I would like to have that kind of quick and responsive environment on the Net as well.

      I'm not saying that you shouldn't read the manual, because you really should! I'm saying that sometimes you learn better by getting a quick solution to your immediate problem than you do by getting a reference to The Whole Picture(tm) in the form of a dense man page when you're not ready for it.

      Knowledge doesn't expand 100% to new areas all at once. It slowly grows and deepens by internalizing what you read and do. When you have the personal experience of doing something you are so much more prepared to understand the theoretical base of that "something".


        There are degrees. At my stage in Perl knowlege, I will get a lot more from a quick answer because I can understand various thing surrounding the issue I need an immediate solution/answer for. I don't think I have come across too many newbies (or any) who can get a quick answer and actually learn from it, without asking 10 other questions. This is why learning to read the docs (et al) are useful for this skill level because they can find the answers to their questions, and side-knowlege along the way. It will also help them learn to learn for those times when they do not have three other programmers around them to ask questions to. I'm saying that sometimes you learn better by getting a quick solution to your immediate problem than you do by getting a reference to The Whole Picture(tm) in the form of a dense man page when you're not ready for it.

        Which do you think would help someone learn better if they ask the simple "how to I remove whitespace from a string?". By you showing them the regex so they can cut/paste it? Or by being refered to perlre and the FAQ (of which that is a question in)? I believe the later is a more effective way. It will take longer to grasp a concept by trying to learn by sound bits and specific snippets (like the regex only). The knowlege one would take from reading perlre to find their answer would in turn answer future questions.

        I am not sure what dense man page you are talking about. Most of the Perl documentation is quite verbose and well explained (with some exceptions). And, when do you propose someone is ready to learn from the documentation of the product they are using? After a year? After asking every FAQ question to cow-orkers and people on the internet?

        Personally, I learned Perl from reading the documentation and learning how other peoples scripts worked (and didn't work). No classes, no mono-a-mano.

        Knowledge doesn't expand 100% to new areas all at once. It slowly grows and deepens by internalizing what you read and do. When you have the personal experience of doing something you are so much more prepared to understand the theoretical base of that "something".

        Yes, so someone needs to read and do to learn.. not ask for 'the answer'. This whole discussion came about from wondering about simple questions from newbies, not about needing quick solutions to complex problems. If people are spoon fed answers from early on, they may not learn the tools needed to fend for themselves.


RE: Are there questions to basic?
by Dogg (Scribe) on Oct 11, 2000 at 18:09 UTC
    I think it is important to remember that sometimes it is difficult to know what to look up in the documentation.

    I'll give an example from my own experience. When I first used PerlMonks, I was very new to Perl (5 days or so) and I was trying to search for all the positions of a regrex in a string (original post here). I knew about index, but had not yet come across the pos function in my reading.
    Sure, I would have read about it eventually as I learned the language, but I was learning the language by writing this program. Maybe I was over-reaching, but I was trying to solve a problem. I couldn't look up a function I didn't know the name of, so I posted a simple question.

    The two excellent responses by Russ and btrott were just what I needed. They gave me the answer (the pos function), a little about the function, and even some sample code. From there, I was able to look up more on the pos function and continue programming and learning perl without delay.

    Without knowing about pos, it would have taken me a while to discover it on my own. There are definitely questions that are too basic, but (aside from homework questions) they really don't hurt anything.

    If you feel a question is too simple, just don't answer it. That might let someone a little less experienced in the language answer it and help someone out.

    Again, my thanks to Russ and btrott, who helped me with what was a simple question.
RE: Are there questions too basic?
by Albannach (Prior) on Oct 11, 2000 at 17:07 UTC
    Are there questions that are too basic? Should a newbie be required to pour over the docs for answers that we can provide in 5 seconds?

    Required is hard, but gently threatened would be good I think. Evidently I've got too much self-imposed restraint, but I'd rather look something up and figure it out myself at least until I'm really stumped, rather than ask a bunch of experts before I've even composed the question in my mind, no matter how friendly they may be.

    I just remember being really green, and not even knowing how to get at the docs to review them

    I've been green for many years now, but I know where the docs are, and I've got the books. Perhaps when an unknown monk tries to post, the page starts with a carefully selected and annotated group of links (the docs, tutorials etc.), also the SuperSearch, and they'd have to scroll through this to get to the edit box. The main benefit to the unknown monk would be an instant answer, not to mention significantly reduced hazing.

    The root of the problem is probably the same thing that stopped me from reading c.l.p several years ago: everyone that has manage to cobble together a home page then wants to get into CGI, and they leap into Perl eyes closed and holding their nose, thinking it's just fancy HTML. The kicker is the old "please e-mail the answer as I don't monitor this group". Is being "unknown" a similar thing? Should you at least be required to register and amass some XP by reading before being permitted to post? (what's the fun in -- unknown? ;-)

    I don't know the answer but maybe there is some entropy-related rule that any repoistory of concentrated knowledge is doomed to be diluted by poorly-typed homework requests.

RE: Are there questions to basic?
by mirod (Canon) on Oct 11, 2000 at 16:47 UTC

    The problem with some questions is that they just show that the posters want to do things that are a tad too complex for for them right now. Which they might not even realize.

    It is often obvious that the poster will not fully understand the answer unless they look at the doc. Hence the you should really grab a book chant and the answer.

    Just giving the answer would probably result in some kind of cargo-cult programming. I think that exhorting the poster to read some more about the answer is the quickest path to enlightment.


RE: Are there questions to basic?
by Blue (Hermit) on Oct 11, 2000 at 17:49 UTC
    I'm a big fan of the "you should go read the docs" *and* "here's an answer". I was self taught in perl, originally from a really lousy book and perldocs. I tell you, that book left me with some moderately bad Perl habits, but also left me at a point where I didn't know something existed so I could look into it further.

    Think about all the power of Perl, but not knowing it. Driving a car that you only knew had first gear. My original world of Perl was defined so narrow that for most tasks, I only knew of one way to do things, a bad place to be for Perl.

    Even after I started learning more, I wasn't fluent with what modules were on CPAN, and what wheels have already been invented. I'm still not near the point I want to be.

    All this is leading to the point of simple questions may open up worlds to people new to Perl. A simple indication to read the docs may not reveal other ways to do things to those struggling, where a code snippet or a reference may.

    But you still need to understand, so a enjoiner to look at the docs is still in order. But even better would be a pointer to the appropriate docs - be it in perldocs, a name of a favorite book (or publisher) that covers it, etc. It really encourages people.

    =Blue might be eaten by a grue...

RE: Are there questions to basic?
by chromatic (Archbishop) on Oct 12, 2000 at 00:06 UTC
    Like all good answers, it depends.

    One of the strengths of Perl as it relates to learning the language is that it's possible to get a frightening amount of work done with a very small subset of the language.

    A bigger strength is that there's usually a much more concise and efficient way to do it. Showing less experienced programmers these techniques is a very good thing.

    The trouble is, how do you teach them to recognize when one solution is better than the other? How do you help a new programmer discern between different approaches?

    Take a look through the Perl FAQ sometime with a beginner's eye and see if you can figure out *why* underexperienced coders are drawn to symbolic references and other easy-to-do-but-hard-to-do-appropriately things.

    One of the few shortcomings of the assembled documentation is that it sometimes doesn't explain *why*. That's something I had to learn through experience (making mistakes in Perl and programming a half dozen other languages).

    No matter what kind of answer you give, you're depriving the supplicant of some of the benefit if you don't go into why things are done the way they are. Experience is a good teacher, but it's not a gentle one. Reading the documentation is very good, but it's no substitute for already knowing how to program in general.

    (spurred on by this line of thought, I'm thinking of writing something like 'Common Mistakes of Beginning Programmers' along the lines of Common Regex Gotchas or whatever I called it way back when. anyone interested?)

      Yes! Very!

      (I'm trying to learn on my own, but I'm being asked to produce production scripts without formal training or time to research. Even the most trivial script is taking days (or longer) to finish...sadly, I am only now beginning to feel like I understand the basics.

      Going back to the original question, I'm in the camp that says "No, no question is too basic." A bit of background may help; I frequent a community support newsgroup and have been involved with that community for ~10 years, so I'm very grounded in the package.

      Many times, I have responded to overly basic questions with stock answers and then learned something new from the follow-up.

      Just because you know a few, some, or many intracacies of a product, language, or process doesn't mean that you can't learn more about it.

Are their questions too basic? Perhaps?
by frankus (Priest) on Oct 12, 2000 at 13:02 UTC
    I am annoyed as I used up all my votes today to ++ most of these posts. If I see someone making sense and being fair I can't help myself.

    I feel that there are some simple questions asked, Bod knows I've asked enough of them. How can you define a level at which you are spoon feeding someone, surely it will be in the Monastery as it is in Development: The serial quizzer will be noted and dealt with by each individual.

    We've all been the novice and needed help, and sometimes we need to spread the word of the good books, a new Monk mightn't know of the books or realise their importance as reference.

    Brother Frankus.

RE: Are there questions to basic?
by PsychoSpunk (Hermit) on Oct 11, 2000 at 21:11 UTC
    I guess the assumption is being made that only green users will ask "basic questions". Or at least, they are more likely to commit the fallacy of not looking through documentation before posting.

    But I'd like to posit that even though I have excellent resource material in front of me (close to the whole O'Reilly Perl series), there are still situations where it would be more appropriate for me to ask a question here. In many of these cases, it's more of a situation where I will take the time to ponder the solutions after the fact of implemenation and try to dissect them into their operative mannerism. I'm willing to argue that a green question is good, as long as the end result is productive learning.

    The obvious problem is that there is no way to gauge if a solution will facilitate productive learning, since the user is not obligated to follow up. So, this is a matter of faith. I have to trust that if I provide a solution to a green question, I am helping the asker to learn something.

    And one final note on this topic: I know that Perl, Linux, and this general area of computing is supposed to be a community. It is important for newbies to understand that by joining this community, you are hereby obligated to read a lot of documentation, to expect that the quick and easy path will lead to Visual Basic style development, and a mixture of help and chastisement. It is important for seasoned vets to aid and to scorn. But I'm going to argue that the two must work hand in hand to create a better community. As an experienced developer with certain areas, I don't want to just give out easy answers all the time. But it's also kind of a civic duty to do more than shout RTFM at the drop of a hat.

    It's been my experience in the past that a good majority of us probably know how to make snide comments that appear within helpful answers. It's one of the facets of many of the geek communities I've been in, and I'd argue that it is an important facet that controls the hierarchy of the group. It creates a healthy competition to become better.


Too basic isn't the issue...
by indigo (Scribe) on Oct 13, 2000 at 01:18 UTC
    Basic questions aren't the problem. "What is a hash?" is a very basic question, one I have no problem answering because you could read the docs ten times, and until you make that conceptual hop, you aren't going to grok hashes.

    The basic nature of some questions mask fundamental ignorance and/or discourtesy many find so annoying. Instead of wondering whether basic questions are bad, we should discourage bad questions in general. Here are some phenotypes that appear to be too basic, but are bad for other reasons:

    "This script doesn't work when the input is 6. Why?"
    Beats me. Make the effort to describe your script, your problem, and what you have tried, or dial Psychic Friends next time.

    "Help me, dammit!"
    The people here provide help as a courtesy. They are under no obligation to help you, doubly so if you are rude.

    I will be glad to provide you Perl support on demand. Let me know where to fax my fee schedule. Otherwise, if you are expecting professional services for free, you business model is fundamentally flawed.

    "I need a program to download satellite telemetry data into a web acessible proprietary database. Please write it."
    see above

    "I have this CGI script with Javascript that uses this C program to run some SQL to load to a mySQL database, and..."
    Figure out which technology is failing you. If it is Perl, let us know.

    "I don't care about Perl, I just want this to program work."
    Well, we do care about Perl, and the purpose of forums like this is to foment community and advocate its use. Friendly help is a happy side effect. Free tech support is not. If you wish results without illumination, you should hire a real Perl programmer, and consider a career in middle management.
      Add "I'm too stupid to format my post correctly" to the list


      Update: Kudos to tilly for reminding me this isn't Slashdot...
RE: Are there questions to basic?
by Trimbach (Curate) on Oct 12, 2000 at 06:29 UTC
    I am personnally very wary of rating any question from anyone as "too basic." Flamers/jokers/homework cheaters aside, I'm not sure it's possible to consistently tell the difference between 1) someone who's lazy and hasn't bothered to check the docs and 2) someone who's CHECKED the docs and stil don't understand.

    The most fundamental information (in any subject, not just Perl) is often skipped in the documentation under the assumption that "everyone knows that." (Try to find a definition of a "four banger" in a engine strip-down manual. I dare you.) Well, I for one can say everyone doesn't. I learned Perl with Programming Perl in one hand and the Perl docs in the other and there were many, many frustrating times when one or the other (or both!) would say something akin to "This is just like x function in Unix" or give code examples on how to do something with no explanation. There was an assumption of a basic level of knowledge that didn't exist in my case. I would have given my eye-teeth for a good explanation of grep, or a good definition of what the heck a character class was. Too basic? RTFM? Not in my case...

    Maybe it's because I'm not burned out after years of c.l.p dealing with newbies, but my first inclination is to say that all who come here seeking knowledge are worthy, and should be treated, at minimum, gently. The question might look stupid to you, but surely going to the trouble to seek out the Monestary and type in a coherent question should count for something. When you see an easy question, please answer it as a teacher would, addressing the scope, level, and desire of the student.

    And if you can't do that, at least be quiet while those of us with more patience take care of it for you.

    Gary Blackburn
    Trained Killer

RE: Are there questions to basic?
by extremely (Priest) on Oct 12, 2000 at 03:08 UTC
    There are questions too basic. =P

    More importantly, there are answers too available, we should at least try and steer them there. My rules are a little more complex on whether or not to ANSWER the question.

    1. Are they Anon? That's a big strike, if they haven't bothered to login and thus aren't planning on staying here to help out, why would I spend much time on em? OTOH, some of the best questions are Anon so I read em all =)

    2. Homework. I will no longer respond to em, you're doing them a disservice by "helping" them.

    3. Spastics. There are some people who seem to just post all kinds of weird, semi-off-topic posts and start flame-wars just for the gratification of seeing their name on the web. I left c.l.p.m years ago over that and FAQ posting. When the channel is 90% karma-whore/spastic and FAQ questions, it's time to leave.

    4. Trying to learn. That phrase is usually a bad sign, as it is generally an amulet held up against expected shouts of "that is a module!" and "why do that with THAT?" I do approve of learning through doing tho so I usually bite on these but I don't often spend the extra time I do on other posts, I just answer the question and let em stew in their own juices.

    5. Performance. This word is a giant red blink tag of evil. I'm either going to bail out immediately if it is tied to phrases like (question the, of module, OOP) or spend hours there tinkering with useless speed enhancements.

    Ahh this will turn rantish if I continue, keep the good questions coming =)

    $you = new YOU;
    honk() if $you->love(perl)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://36207]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2020-07-12 10:16 GMT
Find Nodes?
    Voting Booth?

    No recent polls found