I don't believe Peter Duniho's barking up the wrong tree - he sees room for improvement, and wants to discuss what to do to make it happen. I.e. he appears to care about making the platform better (probably something we all share)...

These are the main valid issues from my point of view:

1 Apple's docs, particularly in relation to Objective-C & Cocoa, have some room for improvement: - e.g. navigation (can't go back to list of methods after clicking a method name hyperlink for example)
  - lack of and generally un-useful sample code
  - too much "cocoa is wonderful" vs. not enough dry detail

2 Cocoa requires you when learning to implement things by clicking and dragging, which makes learning harder for some people (this is a real annoyance to me, why can we not see/edit these connections in a text file? why is there so much other crap in the nib xml? etc).

3 There's a belief (among) that Cocoa is in some way special and these documentation (or more general) shortcomings/issues are not relevant or real or justified.

So, ignoring my usual cynicism (I don't believe there's much that us developers can do to contribute to improving the documentation, or the fact that dragging connections is necessary, though I do submit feedback when I see a clearly-fixable issue), I think it is very valid to raise such issues and discuss them on the mailing list.

thanks for a very interesting and enlightening discussion
Rua HM.

On May 22, 2008, at 5:30 AM, Peter Duniho wrote:

On May 21, 2008, at 1:42 AM, Hamish Allan wrote:

I'm getting lost as to whether your main objection is about Apple not
providing anything other than Objective-C / Cocoa to develop apps on
the Mac, or whether it's just that you think their documentation could
be improved.

Sorry, that's fair. I have a number of concerns, and I admit that I tend to hop around a little (we have one subject description but really several side-topics related to it).

As far as your question goes, the answer is "neither".  And "both".

My _main_ objection is how newcomers to Mac development are treated. Please, when someone new to the current Mac development environment brings up one or more of these points, don't say "well, you're too inexperienced to see why [Obj-C|Cocoa|the documentation| the tools] is/are so great". Don't say "you're riff-raff, it's supposed to be hard, we _like_ that it's keeping you out". Don't say "you must not have read the conceptual guides, otherwise all this would be clear". Or any of the other condescending, presumptuous things that I've seen said on a semi-regular basis.

The fact is, any of those _might_ be true with respect to a specific person. But they aren't necessarily so, and whether it is true or not, it's counter-productive.

Instead, say something like "your complaint is a common one, you aren't alone, and [most importantly] it's legitimate to have these concerns", acknowledging that even if someone's concern is somewhat irrelevant (being regarding a fundamental design aspect of the language or framework, for example), it does color their perception and affect how they approach the development environment. And then move directly to offering specific and constructive help with specific problems. If someone has failed to state their own concerns or problems in a way that allows for this kind of specific, constructive help, just ask questions that will elicit the kind of details that would allow for that.

There are in fact specific things about the development environment that I think can be improved, and I'd start with the documentation. Would making an authoritative text like Hillegaas's book available free online be welcome? Sure. But ultimately, some thought needs to be put into how to make the regular documentation better. More code samples (if not embedded itself, then at least with prominent links embedded within the relevant topic), links to relevant guides where Cocoa concepts are referenced but not defined, fleshing out of specific techniques, and most importantly: keeping the information up-to-date (don't tell me to use a tool that's not even included with the development environment any more, and make sure tool- specific documentation refers to the version of the tool that is current).

But mainly treating people's own impressions and feelings with more respect would go a long way. I recognize that this isn't something most programmers are naturally good at, but inasmuch as the Mac is _supposed_ to be the more "human" platform, IMHO it makes sense that the developer community could stand to observe the more "human" aspects of interpersonal communication.

And by the way, as far as the "shareholder" part of your reply goes: I don't hold Apple stock directly. But everyone who relies on Apple's hardware and software as part of their business, or has any vested interest in the success of the Mac, is in some way a shareholder. In that sense I am a shareholder, and it does concern me to see things that limit the potential success of the Mac. I think it's great that Apple has been able to expand their market share a bit, but it remains to be seen whether their momentum can continue without some fundamental improvements in developer support (why this is, is a whole other topic unto itself, so I won't get into the specifics here).

Pete
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/r.haszardmorris%40adinstruments.com

This email sent to [EMAIL PROTECTED]

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to