Re: Flame retardant
Re: Flame retardant
- Subject: Re: Flame retardant
- From: email@hidden
- Date: Wed, 22 May 2002 11:49:19 -0700
Nathan Zamecnik wrote:
|I think a lot of people, when critisizing beginers is that they don't always
|have Cocoa questions but programming questions that are rather
|elementary....this is not a list for Objective-C exactally
Actually, it *is* for Objective-C "exactally". If you examine the list of Apple mailing lists (at
http://www.lists.apple.com/mailman/listinfo/), you'll see that, athough there is a java-dev list and a fortran-dev list, there is no "objectivec-dev" list. Cocoa and Objective-C are "deeply intertwingled" (to steal a phrase from Ted Nelson), at least as they relate to OS X. They are so "intertwingled", in fact, that one simply cannot use Objective-C on OS X without also using Cocoa. (As but one example: how often are classes declared that are *not* a subclass of NSObject? Yet NSObject is not part of the Objective-C language, but of the Cocoa framework.) Hence, there is no clear line between Objective-C and Cocoa, and questions about Objective-C are entirely appropriate for this list.
|although the occasional question doesn't hurt, some people post question
|after question when the answer is in the documentation on their computer
On the other hand, although the occasional bit of sharpness in a reply doesn't hurt, some people post reply after reply without taking care not to be offensive and rude.
|even basic C questions are asked.
I don't see the problem here. Objective-C is a superset of C, so you can't write Objective-C without also writing plain C, too. What if the book he's learning from failed to address whatever he's asking about? (For that matter, I don't see a problem with C++ questions, since the Apple tools support "Objective-C++" with the simple change of file extension to ".mm". [There's no Apple C++ mailing list, either.])
|A bad question is "where can I get Cocoa docs and books?!" and believe me,
|we get that a lot.
Odd, I don't recall that being a particularly frequent question. In any case, it sounds as if you don't want people asking questions that are in the documentation, but don't want them asking where to find the documentation, either. What, then, are they to do?
|Personally, I ignore these types of questions by not even considering a
|reply, mainly because I don't want to make anyone feel bad with what my
|reply would be, but I still have to read it and then delete.
I applaud your restraint; if others followed the same practice, this discussion would likely not be taking place. As to having to read the messages, that's the price of being on a mailing list that is expressly intended to support beginners (among others). (Apple has said it is, and they should know.)
|I just wish people would consult the documentation more and stop asking
|questions on VERY basic things, unless it's very relevant.
And who decides what is "very relevant"? You or them? If they're stuck by something "VERY basic", it is *extremely* relevant to the person asking, since he or she can't go forward without an answer. If you had a question that someone else considered "VERY basic", but which was utterly baffling to you, would you appreciate being told only "it's in the documentation, go read it"? Or would you prefer at least "the pressTheRedButton: method of NSBlinkingLights will probably do what you want; the documentation will give you the details"? (Over the course of many exchanges here, I've gotten the impression that beginners are perfectly willing to read the documenation. They just don't know what part of the documenation to read. Tell them that, and do it nicely, and generally they're happy.)
|I do not consider myself a Cocoa master, but I can make a decent program and
|discuss Cocoa topics but if I am stuck on something, like "how can I make an
|NSString do this?" I will look in the NSString docs and find it, instead
|many other people are lazy and do not want to consult their docs and end up
|asking a question like that.
How do you know it's laziness that prompts the question? I think I've seen only one or two messages that said "I'm too lazy to look this up," and those struck me as tongue-in-cheek. Perhaps the asker has tried to read the documentation, and found it too terse, or that it assumes knowledge that he hasn't yet acquired. Perhaps his eyes just glazed over at the wrong time. (How many questions from *experts* have been resolved with those classic words, "how did I miss *that*?"
Consider, for example, the seemingly-obvious NSString method initWithCString:. You could probably use it successfully without even consulting the documentation, simply by knowing the name. (What, after all, could a method named "initWithCString:" do other than initialize an NSString with the characters in a C string?) But read what the documentation actually says:
Initializes the receiver, a newly allocated NSString, by converting the
characters in cString from the default C string encoding into the
Unicode character encoding. cString must be a zero-terminated C string
in the default C string encoding, and may not be nil.
I can easily imagine a beginner seeing that and being utterly bewildered. "Receiver? Unicode? String encoding? Character encodings? All I want to do is make an NSString. I'm not using Unicode or character encodings, whatever they are." Yes, you can argue that he should already know these things, but then you will get questions like "What's Unicode, and how do I write a string in it?" or "I've allocated an object; how do I find its receiver?" The problem is precisely that a beginner *doesn't know much*; he hasn't had the chance to learn the great number of things that more experienced people regard as trivial or obvious, or to match up the different ways you can say the same thing. Yes, you know what Unicode is, and so do I. But very few C books (or Objective-C books, for that matter) are going to so much as mention it. (Unicode is, after all, a 16-bit character code; C characters are [in all implementations I know of] 8-bit quantities. Since you can't store Unicode in a C "cha!
r", why talk about it?)
Worse: if the beginner *keeps* reading, he'll find the initWithUTF8String: method, which says only "Initializes the receiver, a newly allocated NSString, by copying the characters from bytes." Now he'll really be confused, because initWithUTF8String: appears to do what he wants, if only he had a UTF8String, whatever that is. So now you'll get the question, "how do I convert a C string to a UTF8String?", which would likely be jumped on as being too simple, since C strings *are* UTF-8 strings.
He can't win, no matter what he asks, because *any* question he could ask is "too simple".
|Questions the documentation can directly answer with a simple look up (get
|Cocoa Browser) are bad, questions on concepts are good.
What's a "simple look up" to you may not be so simple to someone who hasn't gotten the hang of the structure (or lack therefore) of the documentation. Also, there is information on "concepts" throughout the documentation. (Apple divides the stuff into Concepts and Tasks, after all.) Aren't "questions on concepts" thus things that can be answered by a "simple look up" of the documentation? Further, you blithely toss in, "get Cocoa Browser", as if *everyone* knows what that is, or where to get it. So the beginner must now get tools he hasn't heard of from a web site he doesn't know about in order to read documenation he doesn't understand before he's entitled to ask questions? I fail to see how this is reasonable. (And would asking where to get Cocoa Browser be any more acceptable than asking "where can I get Cocoa docs and books?!")
|Also, a note to the newbies, looking through the docs is good....I mean
|spend serious time in them....have a question, look it up and you will be
|amazed with what else you learn...I sometimes think of ideas I cannot solve
|just to look through the docs and discover more....when I have time anyways.
Very good advice. I don't doubt that there are *experienced* people who would benefit from doing this. (I probably would, myself.) I wonder, though: did you do this from the very beginning, or did it take time for you to discover that all manner of pearls of knowledge could be found from random digging through the documentation? Different people have different styles of learning, after all, and even if the value of that sort of browsing was apparent to you from day 1, it won't necessarily be apparent to others. Second, there's that nasty caveat, "when I have time". Beginners have a great deal to learn before they can become "self-sustaining", really capable of finding their own answers. There are concepts to comprehend, jargon to memorize, documentation to organize. If they haven't a clue where to look (and, lacking the conceptual framework that is constructed as you learn the ropes, they probably won't), finding the specific bit of information they want could take a lot of ti!
me.
Indeed, this seems to be the very heart of the matter: it takes time to learn *how* to find answers; it's not a skill that comes built into the human brain. Beginners, *because they are beginners*, haven't yet mastered finding answers. This means that, inevitably, you will get questions from people who have discovered one way of finding answers--asking the list--without having found other ways--reading the documentation, searching the web. Having found a way to do something that works (or seems to), it's human nature to *keep* doing things that way. This is not to excuse beginners from learning those other ways; they are important, and it's right and proper to *inform* beginners of those ways, so long as the informing is done with courtesy. But I think beginners deserve a little more slack than people are giving them.
Too, by the nature of being a beginner, there will always be *new* beginners. There will *always* be people who haven't yet mastered the skill of finding answers. *This* is why there seems to be no end to "VERY basic" questions: not because beginners aren't becoming more advanced, but because there is no end to the people who are just starting out. Yes, it's the three millionth time you've answered that question. But it's only the first time they've asked it.
|Thank's for reading my rant.
Actually, your language was far too tempered to be a good rant. I saw this as a fairly level-headed presentation of one person's opinion. I don't agree with it (as you have no doubt figured out), and I could pick a few nits with the presentation, but I wouldn't tar this with the label "rant". Rather, I regard it as a reasonable contribution to the discussion.
Glen Fisher
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.