Guidance for Cocoa's steep learning curve
-
The obstacles, misconceptions, and prerequisite concepts that need to
be mastered when learning Cocoa vary dramatically based on the past
experience of the learner. I am a very experienced Cocoa programmer.
I am also an author of the thickest Cocoa Programming book and have
another Cocoa book due out real soon. I have some guidance.
To relate my background, I started using NeXTstep (the precursor to
Cocoa) that included Interface Builder and Objective-C and App Kit in
late 1988. I had heard of object oriented programming but didn't "get
it". I had attended a one day seminar on "C with Classes" which later
became C++. I left the seminar no wiser than when I arrived. I had
worked for eight years with C and a variety of assembly languages. I
had been using Ada for a year.
I became excited about NeXTstep software development, worked on many
hobby projects, and from 1991 on I worked extensively with NeXTstep/
Openstep/YelowBox/Cocoa as well as C++ and many other technologies. I
founded a company in the early 90s and developed an industry leading
application. I sold the intellectual property to a Fortune 500
company in 1996, and my company continued to work in the industry
until late 2002. I am now "Senior Staff" for a different Fortune 500
company in a related industry.
Here is my guidance based on some arbitrarily chosen categories of
learners:
=== If you have never programmed before
1) Learn any programming language (it may seem hard, but every 'real'
programmer knows many languages and you have to start somewhere)
2) Learn C and at least learn to recognize low level operations like
bit manipulation, pointers, intrinsic types, pointers to pointers,
pointers to functions, etc. Without this, you will be lost and
dangerous when writing Cocoa programs in Objective-C.
3) Learn Objective-C. It takes about 1 day for an experienced C
programmer.
4) Start the long process of learning the Cocoa frameworks, the C
standard library, and some of the Unix libraries.
4A) Learn Cocoa conventions and common patterns. These are not
optional. Clear understanding of the following is required to write
graphical Cocoa applications: two stage allocation and initialization,
designated initializers, memory management, selectors, dynamic
messaging, accessors, the responder chain, delegates, target/action,
data sources, archiving & unarchiving (e.g. freeze dried objects
in .nib files), the view hierarchy, key and main windows, and above
all the Model View Controller pattern.
4B) Study Apple's sample applications, work tutorials, experiment, and
build a few hobby projects.
=== If you are primarily an experienced "dynamic" language programmer
(perl, Ruby, Python, Smalltalk, TCL, etc)
1) Learn C and at least learn to recognize low level operations like
bit manipulation, pointers, intrinsic types, pointers to pointers,
pointers to functions, etc. Without this, you will be lost and
dangerous when writing Cocoa programs in Objective-C.
2) Learn why C and therefore Objective C use a pre-processor with
separate headers and separate implementation files. Come to grips
with the edit, COMPILE, link, debug cycle.
3) Learn Objective-C. It takes about 1 day. You will realize the
Objective-C is very dynamic and flexible but has its own idioms.
4) Start the long process of learning the Cocoa frameworks, the C
standard library, and some of the Unix libraries.
4A) Learn Cocoa conventions and common patterns. Many will be
familiar to a Smalltalk programmer. These are not optional. Clear
understanding of the following is required to write graphical Cocoa
applications: two stage allocation and initialization, designated
initializers, memory management, selectors, dynamic messaging,
accessors, the responder chain, delegates, target/action, data
sources, archiving & unarchiving (e.g. freeze dried objects in .nib
files), the view hierarchy, key and main windows, and above all the
Model View Controller pattern.
4B) Study Apple's sample applications, work tutorials, experiment, and
build a few hobby projects.
4C) If you object to Cocoa's memory management conventions, learn to
love them because in the world of C, automatic garbage collection can
not solve all of your problems.
=== If you are primarily an experienced C++ programmer (In my
experience you will have the hardest time)
1) Forget everything you think you know about Object Oriented
programming (no offense intended).
2) Break every ingrained C++ habit and idiom because the design
philosophy of Objective-C and Cocoa is exactly the opposite of almost
everything C++ encourages.
3) Learn Objective-C. It takes about 1 day for an experienced C
programmer. You will realize the Objective-C is very dynamic an
flexible. Many patterns and idioms in C++ are unneeded in Objective-
C. Objective-C classes tend to be more high level and straight
forward, and you tend to use fewer of them. You may feel disoriented
without the accustomed "bondage and Discipline" [http://c2.com/cgi/wiki?BondageAndDisciplineLanguage
], but I strongly advise you to learn an appreciation for freedom and
the flexibility to send any message to any object even if the receiver
did not exist when your application was compiled and linked. For
many, an appreciation for Cocoa's undo mechanism breaks the ice.
(although dynamism is ubiquitous in Cocoa)
4) Start the long process of learning the Cocoa frameworks.
4A) Learn Cocoa conventions and common patterns. These are not
optional. Clear understanding of the following is required to write
graphical Cocoa applications: two stage allocation and initialization,
designated initializers, memory management, selectors, dynamic
messaging, accessors, the responder chain, delegates, target/action,
data sources, archiving & unarchiving (e.g. freeze dried objects
in .nib files), the view hierarchy, key and main windows, and above
all the Model View Controller pattern.
4B) Study Apple's sample applications, work tutorials, experiment, and
build a few hobby projects.
=== If you are primarily a Java programmer
1) Learn Objective-C. It takes about 1 day. You will realize the
Objective-C is very dynamic and flexible. Many patterns and idioms in
Java and C# are unneeded in Objective-C. You may feel disoriented
without the accustomed "bondage and Discipline"[http://c2.com/cgi/wiki?BondageAndDisciplineLanguage
], but I strongly advise you to learn an appreciation for freedom and
the flexibility to send any message to any object.
2) Start the long process of learning the Cocoa frameworks, the C
standard library, and some of the Unix libraries.
2A) Learn Cocoa conventions and common patterns. These are not
optional. Clear understanding of the following is required to write
graphical Cocoa applications: two stage allocation and initialization,
designated initializers, memory management, selectors, dynamic
messaging, accessors, the responder chain, delegates, target/action,
data sources, archiving & unarchiving (e.g. freeze dried objects
in .nib files), the view hierarchy, key and main windows, and above
all the Model View Controller pattern.
2B) Study Apple's sample applications, work tutorials, experiment, and
build a few hobby projects.
=== All
Once you understand in principal how all of the basic Cocoa patterns
are implemented, learn about Key Value Observing, Bindings, Core Data,
etc. These use advanced patterns that seem like magic until you have
mastered the basics. -
On May 14, 2008, at 8:19 PM, Erik Buck wrote:
<very useful language-based analysis snipped>
I would just like to add the following:
(1) It also depends upon prior framework experience as to how easy or
difficult it will be to dive into Cocoa. I learned event-driven
programming very early and had the advantage of either using or
authoring ten other frameworks prior to using Cocoa.
For me, Cocoa was just another new framework to learn. I thus had
experience in ramping up to frameworks and found the transition quite
easy.
> === If you are primarily an experienced C++ programmer (In my
> experience you will have the hardest time)
(2) I will have to personally disagree with this. I found the
transition from C++ to Obj-C to again be easy. I also chose to go
pure Obj-C rather than mix in existing C++ classes. This was a
personal choice and by no means would I recommend this path for
everyone; mixing in C++ is often the right thing to do.
I will agree though that you have to throw certain C++ mindsets out
the window. But, as with any new language/framework, there are always
different philosophies of what one should/shouldn't do.
FYI, my personal path of languages has been: AppleSoft and other forms
of BASIC; Assembly (mostly 6502); Pascal; C; C with objects*; C++;
Java; Obj-C. Along the way, dabbled a tiny bit in Scheme, ADA,
Smalltalk and Prograf.
* I purchased the follow-on product to Think C which sometimes
referred to as "C+". It had a very small set of keywords added to
provide developers with basic OO support.
___________________________________________________________
Ricky A. Sharp mailto:<rsharp...>
Instant Interactive(tm) http://www.instantinteractive.com -
>> === If you are primarily an experienced C++ programmer (In my
>> experience you will have the hardest time)
>
>
> (2) I will have to personally disagree with this.
I wonder, seriously, if it doesn't depend somewhat on whether or not you're
a really good C++ programmer...
--
Scott Ribe
<scott_ribe...>
http://www.killerbytes.com/
(303) 722-0567 voice -
On Wed, May 14, 2008 at 11:33 PM, Scott Ribe <scott_ribe...> wrote:
>>> === If you are primarily an experienced C++ programmer (In my
>>> experience you will have the hardest time)
>>
>>
>> (2) I will have to personally disagree with this.
>
> I wonder, seriously, if it doesn't depend somewhat on whether or not you're
> a really good C++ programmer...
>
I'd say it depends more on the type of C++ programming you're coming
from. If you're coming from a purely procedural background with no
event-driven experience, some pretty fundamental Coca concepts are
going to be problematic. If you're comfortable with C++ strict typing
rules, Objective-C may appear to have too much runtime magic going on.
On the other hand, if you've spent a lot of time abusing void * to
hack runtime dynamism into C++, Objective-C will be a breath of fresh
air ("You mean I can do this with sane syntax rather than lots of
casts and abuses of types?"). Also, memory management may throw you
for a loop if you haven't seen reference counting before; if you've
implemented it in C++ out of frustration, however, it's quite clear.
When I was first learning Cocoa and Objective-C, coming from more of a
systems programming background, what made sense of it was to
understand the runtime itself- and there is documentation on it- so
that things ceased to be "black boxes" and I could trace program
control flow without gaps. Once it's clear that methods are just
virtual functions with a different syntax and the ability to actually
determine whether or not they exist at runtime rather than crash,
objective-c is identical to c++ object oriented programming (okay, for
loose definitions of "identical", I don't want to get into the
details; given that insight there are clear broad similarities in
implementation).
So, from a C++ perspective, I'd offer the following points:
1) The type "id" is just void *, except the compiler doesn't complain
when you don't cast it to something real before calling functions on
it as an object.
2) Method calls are just calls to virtual functions, with a little
more runtime support to make them less fragile. In effect,
*everything* in Objective-C is a virtual function; you can't have
non-virtual functions.
3) Instance methods (with the -) are virtual functions. Class methods
(with the +) are static functions.
4) Outlets are just pointers. When your nib gets instantiated with
your object as File's Owner, your outlets (just member variable
pointers) have their values set to point to the things you told them
to point to in the nib.
5) Target-Action setup is just a pointer to an object + a function
pointer. You're telling something "Hey, when X happens, call this
function on this object." Think of callback functions.
There are others, but those are the most basic. Once you can map the
Objective-C constructs onto what's happening under the hood, it
becomes more clear how to take advantage of them.
--
- David T. Wilson
<david.t.wilson...> -
On 14 May '08, at 10:16 PM, David Wilson wrote:
> 3) Instance methods (with the -) are virtual functions. Class
> methods (with the +) are static functions.
Class methods aren't exactly like static functions, because they're
still dynamically dispatched and can be overridden by subclasses.
A closer analogy is to think of there being a singleton "class object"
for every class (which is what -class returns), and the class methods
are instance methods of those class objects. The class objects have an
inheritance hierarchy that parallels the class hierarchy, so if B is a
subclass of A, B's class object will be a subclas of A's class object.
(For more detail, look up "metaclass"; I'm sure there's an abstruse
Wikipedia article about it. The concept goes back to Smalltalk-80, on
which Objective-C's runtime model and syntax were based.)
—Jens
PS: In regards to the thread subject, I didn't find Cocoa to have a
steep learning curve. I took a training class and was amazed at how
easy it was to learn, and to build sophisticated apps with, compared
to every other GUI API or framework I'd used. -
> if you've spent a lot of time abusing void * to
> hack runtime dynamism into C++
Or if you've done it the right way, with templates--was more what I was
thinking...
1-5 are all very good points. Much of what's been said here belongs in an
intro document somewhere...
--
Scott Ribe
<scott_ribe...>
http://www.killerbytes.com/
(303) 722-0567 voice -
Lets add to this fun madness. Nice simple clean tutorials like this
http://cocoadevcentral.com/d/learn_objectivec/
Could cocoa parts in the frame work be summed up like that as well?
How many "examples" or paragraphs and or pages of text does it take to
finally drill down the Cocoa method into your head? Where do you reach
Gestalt and can sum up how these commands are typed onto the page in
Xcode and they just work?
I get messages and oop [Sender Dosomething] or in Ruby
@sender.dosomething. OOP was easy for me as thats how I already
thought code would be like. Of course I am still learning but I fail
to see why Cocoa syntax could be any different than Ruby. I'll test
Macruby when 1.9 comes out, but reading Cocoa is like bash my head
into needless [] : @ syntax every which way.
Ack, back to books to many emails to read. -
Am 15.05.2008 um 03:19 schrieb Erik Buck:
> 2) Learn C and at least learn to recognize low level operations like
> bit manipulation, pointers, intrinsic types, pointers to pointers,
> pointers to functions, etc. Without this, you will be lost and
> dangerous when writing Cocoa programs in Objective-C.
Let me take this opportunity to once again shamelessly plug my C
tutorial:
http://masters-of-the-void.com
which covers most of this (it doesn't cover pointers to functions and
bitwise operations), especially memory management and pointers.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de -
> Let me take this opportunity to once again shamelessly plug my C tutorial:
>
> http://masters-of-the-void.com
>
> which covers most of this (it doesn't cover pointers to functions and
> bitwise operations), especially memory management and pointers.
Shameless plug but oh so nice of a Tut. Thank you. -
On 15 May '08, at 8:21 AM, colo wrote:
> I get messages and oop [Sender Dosomething] or in Ruby
> @sender.dosomething. OOP was easy for me as thats how I already
> thought code would be like. Of course I am still learning but I fail
> to see why Cocoa syntax could be any different than Ruby.
Um, because it's a different language? (Which is, FYI, called
"Objective-C", not "Cocoa".)
Objective-C message syntax is closely based on Smalltalk-80, the
granddaddy* of object-oriented languages. (Ruby is also strongly
Smalltalk-influenced, but in different ways, and ironically its
message syntax is more based on C.)
The idea is that selectors, by intermingling the method name with the
arguments, make the meaning clearer and let you create variant
versions of methods in a simple way.
In Ruby:
obj.useString("bar",true,7) # WTF do all those params mean?
Objective-C:
[obj useString: @"bar" caseSensitive: YES maxLength: 7]; // much
clearer!
Note that you can then add versions of this without the maxLength: and/
or caseSensitive: parameters, or with something else entirely:
[obj useString: @"bar" customTransformer: myTransformer];
which in Ruby would have to be a method called
"useStringWithTransformer" or something like that.
> I'll test Macruby when 1.9 comes out, but reading Cocoa is like bash
> my head into needless [] : @ syntax every which way.
It usually takes people about one day to get used to the syntax.
Complaining about it just because it isn't what you're used to isn't
very productive.
—Jens
* (as opposed to great-granddaddy Smalltalk-72, and family line
founder Simula) -
On May 14, 2008, at 8:33 PM, Scott Ribe wrote:
>>> === If you are primarily an experienced C++ programmer (In my
>>> experience you will have the hardest time)
>>
>>
>> (2) I will have to personally disagree with this.
>
> I wonder, seriously, if it doesn't depend somewhat on whether or not
> you're
> a really good C++ programmer...
I think it depends on whether you actually used C++ for what it is or
just as C with 'class' instead of 'struct' and // comments.
At least from my point of view, I didn't feel at all like C++
knowledge was in the way or that I had to 'unlearn' things. If you've
used a decent OO UI toolkit, STL and BOOST before and read the "gang
of four" book then there's not that much new in Objective-C/Cocoa IMHO.
-Stefan -
> then there's not that much new in Objective-C/Cocoa IMHO.
Exactly. Deferred-release makes reference counting easier. Looser more
dynamic typing makes certain things more convenient & more concise.
Delegation keeps the single-inheritance hierarchy shallow and
comprehensible. The handful of powerful patterns are used consistently and
to very good effect in the overall design. There's no one thing shockingly
different; just a few good ideas applied effectively and consistently. (And,
I should add, with a tolerably lightweight runtime cost for the dynamic
bits.)
Learning the basics of Objective-C & Cocoa was dead easy. Starting to see
the way it all fit together took longer. Getting a grip on the breadth of
the whole framework, or the depth of how to modify behavior of standard
classes--that takes a long time.
--
Scott Ribe
<scott_ribe...>
http://www.killerbytes.com/
(303) 722-0567 voice -
I come from Java, and before, for web and for Windows and i am learning
Cocoa for "Iphone" purposes mainly
For me the biggest issue is to learn the libraries and frameworks (all
these tons of objects)
Cocoa is long away from the "pure c" Win32 library (of microsoft
windows)...But the true is that almost nobody use now "pure c win32" to
write applications
The really first step with a language is allways to write code and
forget the "GUI" and the "buttons and windows" .....Then when you know
what are you doing and you can do what you want to do (like a painter),
you can think in the "GUIS" and all these stuff
Scott Ribe escribió:
>> then there's not that much new in Objective-C/Cocoa IMHO.
>>
>
> Exactly. Deferred-release makes reference counting easier. Looser more
> dynamic typing makes certain things more convenient & more concise.
> Delegation keeps the single-inheritance hierarchy shallow and
> comprehensible. The handful of powerful patterns are used consistently and
> to very good effect in the overall design. There's no one thing shockingly
> different; just a few good ideas applied effectively and consistently. (And,
> I should add, with a tolerably lightweight runtime cost for the dynamic
> bits.)
>
> Learning the basics of Objective-C & Cocoa was dead easy. Starting to see
> the way it all fit together took longer. Getting a grip on the breadth of
> the whole framework, or the depth of how to modify behavior of standard
> classes--that takes a long time.
>
>
-
On May 15, 2008, at 3:39 PM, Bruno Sanz Marino wrote:
> The really first step with a language is allways to write code andI think this is a crucial point.
> forget the "GUI" and the "buttons and windows" .....Then when you
> know what are you doing and you can do what you want to do (like a
> painter), you can think in the "GUIS" and all these stuff
>
My guidance for Cocoa's alleged "steep learning curve" is, "Why are
you making it steep?"
It reminds me of the clichéd joke: "Doctor, it hurts when I do this."
"Well, don't do that."
There are plenty of ways to ease yourself it Cocoa development,
notably just as Bruno suggests here by ignoring the GUI and learning
about the Objective-C language an the basics of the Foundation
Frameworks.
Yet week in, week out, we see people who ignore the advice given in
the documentation and try to learn Objective-C, Foundation, Interface
Builder, *and* Cocoa bindings and Core Data all in one go. It's no
wonder it's daunting.
mmalc -
On 15 May '08, at 5:03 PM, mmalc crawford wrote:
> My guidance for Cocoa's alleged "steep learning curve" is, "Why are
> you making it steep?"
> It reminds me of the clichéd joke: "Doctor, it hurts when I do
> this." "Well, don't do that."
I agree. There are so many questions on this list from people who are
clearly Cocoa newbies, who are trying to do really difficult/advanced
things.
If you're learning Cocoa, just write something straightforward like a
simple app, like the CurrencyConverter or whatever. Learn the basics
of how to write action methods, wire up an interface in IB, and do
basic things with Foundation classes. Add features one at a time ...
documents, copy and paste, drag and drop, whatever. Just don't try to
start out all at once with CoreData and XML and AppleScript and
accessing other apps' windows!
—Jens -
I think what is missing here is some history. I'm working on an APP to
make a series of arbitrary measurements
(i.e. positions, distances angles, shapes) on each of the frames of a
movie. On some movies I might want to make
three position measurements, on others I want to make 4 angle
measurements, etc. Dealing with the movie and
indeed Firewire controlled acquistion and mouse controlled measurement
has been rather cool. What is absolutely
baffling is dealing with NSTableView. The documentation absolutely
sucks. How does one map table rows and columns
on NSMutableArrays and NSMutableDictionaries. How does one map the Rows
and Columns of a "dataSource"
on a NSTable view? What about records and fields. Imagine growing up
on Excel and then dealing with NSTableView.
How did this Cocoa NSTableView architecture evolve. Where is the history?
ja
mmalc crawford wrote:
>
> On May 15, 2008, at 3:39 PM, Bruno Sanz Marino wrote:
>
>> The really first step with a language is allways to write code and
>> forget the "GUI" and the "buttons and windows" .....Then when you
>> know what are you doing and you can do what you want to do (like a
>> painter), you can think in the "GUIS" and all these stuff
>>
> I think this is a crucial point.
>
> My guidance for Cocoa's alleged "steep learning curve" is, "Why are
> you making it steep?"
> It reminds me of the clichéd joke: "Doctor, it hurts when I do this."
> "Well, don't do that."
>
> There are plenty of ways to ease yourself it Cocoa development,
> notably just as Bruno suggests here by ignoring the GUI and learning
> about the Objective-C language an the basics of the Foundation
> Frameworks.
>
> Yet week in, week out, we see people who ignore the advice given in
> the documentation and try to learn Objective-C, Foundation, Interface
> Builder, *and* Cocoa bindings and Core Data all in one go. It's no
> wonder it's daunting.
>
> mmalc
>
--
Joseph Ayers, Professor
Department of Biology and
Marine Science Center
Northeastern University
East Point, Nahant, MA 01908
Phone (781) 581-7370 x309(office), x335(lab)
Cellular (617) 755-7523, FAX: (781) 581-6076
Boston Office 444RI, (617) 373-4044
eMail: <lobster...>
http://www.neurotechnology.neu.edu/ -
On 15 May '08, at 6:33 PM, Joseph Ayers wrote:
> What is absolutely
> baffling is dealing with NSTableView. The documentation absolutely
> sucks. How does one map table rows and columns
> on NSMutableArrays and NSMutableDictionaries. How does one map the
> Rows and Columns of a "dataSource"
> on a NSTable view?
I take it you read the table view programming guide and it didn't help?
file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/Conceptual/TableView/Tasks/UsingTableDataSource.html
Basic table display is simple. As that page says:
>> Your data source object can store records in any way you choose, as
>> long as it is able to identify those records by integer index. It
>> must also implement methods to provide the following information:
>>
>> * How many records are in the data source (numberOfRowsInTableView
>> method)
>>
>> * What is the value of a specific record
>> (tableView:objectValueForTableColumn:row: method)
>>
Lets say you're storing your data as an NSArray of NSDictionaries,
with each dictionary's keys matching the identifiers of the table
columns. Then all you have to do is:
- (int) numberOfRowsInTableView: (NSTableView*)table {
return [_rowArray count];
}
- (id) tableView: (NSTableView*)table objectValueForTableColumn:
(NSTableColumn*)column row: (int)row {
NSString *identifier = [tableColumn identifier];
return [[_rowArray objectAtIndex: row] objectForKey: identifier];
}
> What about records and fields. Imagine growing up on Excel and then
> dealing with NSTableView.
> How did this Cocoa NSTableView architecture evolve. Where is the
> history?
Excel is an application, not an API. All applications present friendly
interfaces to complex functionality behind the scenes. Welcome to the
complex functionality :) I'm sure Excel's internal classes or data
structures are at least as involved as NSTableView.
The key thing is that any generic table view has to support huge
numbers of rows, and arbitrary ways of storing the data. So the view
itself can't store the data for you. Instead it has to ask your code
to fetch each piece of data it needs to display. That's exactly what
those two methods I showed above do.
This isn't an unusual design. Java's Swing table component works the
same way, as did the ones in the old MacApp and PowerPlant frameworks.
—Jens -
On May 15, 2008, at 6:33 PM, Joseph Ayers wrote:
> The documentation absolutely sucks. How does one map table rows andAnd here's another increasingly prevalent problem: a claim that the
> columns on NSMutableArrays and NSMutableDictionaries. How does one
> map the Rows and Columns of a "dataSource" on a NSTable view?
>
documentation sucks and doesn't describe how to perform a particular
task, and yet exactly that task is described in the documentation:
<http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Cla
sses/NSTableView_Class/Reference/Reference.html>
->
<http://developer.apple.com/documentation/Cocoa/Conceptual/TableView/TableVi
ew.html>
->
<http://developer.apple.com/documentation/Cocoa/Conceptual/TableView/Tasks/U
singTableDataSource.html>
mmalc -
Regarding the question on how NSTableView works -- there are examples
of Table Views in the Aaron Hillegass book "Cocoa programming for Mac
OS X". Also, there are literally hundreds of questions and answers on
Table Views in the archives of this mailing list. When I get stuck on
how to do something, my first line of attack is to search the
archives. The archives have a wealth of information.
Jim Merkel -
On May 15, 2008, at 6:33 PM, Joseph Ayers wrote:
> Imagine growing up on Excel and then dealing with NSTableView.
> How did this Cocoa NSTableView architecture evolve. Where is the
> history?
When I first started with Cocoa I spent (and I still spend) a lot of
time in code for NSTableView (and NSOutlineView). A lot of time
because of the complexity of the data model -- caching and maintaining
the caches, spawning threads to render time consuming images,
notifying the data source object when images are ready to be
displayed. You get the idea. Of course, I started with slow tables
that did the expensive rendering every time NSTableView asked for the
data and I built the complexity on top of that.
I started learning how to use NSTableView by reading through
NSTableView.h in Class Browser in Project Builder (pre-Xcode) and
reading the NSTableView documentation that Class Browser gave me. I
learned that numberOfRowsInTableView: was a pretty important method in
using NSTableView, so I went to http://developer.apple.com/ and
searched (search field at top-right of page) for
numberOfRowsInTableView. That gave me a wealth of information --
documentation and sample programs. Compiling and stepping through a
couple sample programs helped me immensely.
There is plenty of documentation and sample programs to help
developers learn this stuff. Take the time to find it, read it,
compile it, step through it, modify it, compile it again, step through
it again, search the archives (http://www.cocoabuilder.com/archive/bydate
), read, then, finally, ask specific clarifying questions.
Oh, and my background? 6 years as an Excel programmer at Microsoft.
It hasn't hindered me at all. :)
john -
The NSTableView is based on the MVC paradigm which has existed for
quite some time. A method you implement gets called to return the
value for each cell (more or less). So if you have a table with forty
cells, then at least 40 times the method will get called. After I
started looking at it this way, the whole NSTableView thing clicked.
The NSTableView docs aren't too bad. Trust me, you haven't hit the
depths of Apple documentation suckage until you hit current
documentation that refers you to documentation written a zillion years
ago where all the example code is in Pascal.
-- Ilan
On May 15, 2008, at 9:33 PM, Joseph Ayers wrote:
> I think what is missing here is some history. I'm working on an APP
> to make a series of arbitrary measurements
> (i.e. positions, distances angles, shapes) on each of the frames of
> a movie. On some movies I might want to make
> three position measurements, on others I want to make 4 angle
> measurements, etc. Dealing with the movie and
> indeed Firewire controlled acquistion and mouse controlled
> measurement has been rather cool. What is absolutely
> baffling is dealing with NSTableView. The documentation absolutely
> sucks. How does one map table rows and columns
> on NSMutableArrays and NSMutableDictionaries. How does one map the
> Rows and Columns of a "dataSource"
> on a NSTable view? What about records and fields. Imagine growing
> up on Excel and then dealing with NSTableView.
> How did this Cocoa NSTableView architecture evolve. Where is the
> history?
>
> ja
>
> mmalc crawford wrote:
>>
>> On May 15, 2008, at 3:39 PM, Bruno Sanz Marino wrote:
>>
>>> The really first step with a language is allways to write code and
>>> forget the "GUI" and the "buttons and windows" .....Then when you
>>> know what are you doing and you can do what you want to do (like a
>>> painter), you can think in the "GUIS" and all these stuff
>>>
>> I think this is a crucial point.
>>
>> My guidance for Cocoa's alleged "steep learning curve" is, "Why are
>> you making it steep?"
>> It reminds me of the clichéd joke: "Doctor, it hurts when I do
>> this." "Well, don't do that."
>>
>> There are plenty of ways to ease yourself it Cocoa development,
>> notably just as Bruno suggests here by ignoring the GUI and
>> learning about the Objective-C language an the basics of the
>> Foundation Frameworks.
>>
>> Yet week in, week out, we see people who ignore the advice given in
>> the documentation and try to learn Objective-C, Foundation,
>> Interface Builder, *and* Cocoa bindings and Core Data all in one
>> go. It's no wonder it's daunting.
>>
>> mmalc
>>
>
> --
> Joseph Ayers, Professor
> Department of Biology and
> Marine Science Center
> Northeastern University
> East Point, Nahant, MA 01908
> Phone (781) 581-7370 x309(office), x335(lab)
> Cellular (617) 755-7523, FAX: (781) 581-6076 Boston Office 444RI,
> (617) 373-4044
> eMail: <lobster...>
> http://www.neurotechnology.neu.edu/
-
I don't mean to be mean, but I agree with Joseph; most Apple
documentation is really, really poor.
*No, that's not correct.* The documentation is extensive, and
comprehensive, but unless you already know what you are reading about,
it might as well have been written in Farsi (no offense meant to any who
speak Farsi--and if Farsi is your first language, then substitute
English for Farsi).
I have found this to be true on most every product's documentation; not
just X Code. It is easily understood after five years of experience.
The beginner struggles with the concepts, the locutions, the native
phrases that the experienced programmer understands.
For example, I was reading up on NSString yesterday and it began
discussing "delegates." What the blazes is a delegate? (Please, no
responses needed.) Open up any Developer page on the Apple site, and
you run into the same thing. Concepts appear that are inadequately
described, or described with so much jargon that even the experienced
programmer (such as myself) has trouble making his way through it.
Some of this might be better dealt with if the document were more
extensively hyperlinked.
Microsoft documentation is the same way--difficult to understand unless
you have learned the lingo. Borland documentation, I have found, is
not, but alas it has such a small market share that it is virtually
ignored.
At least Apple is going through the motions of attempting to get
feedback from its users with the questions added at the bottom of their
documentation. I hope that some day it does some good.
R,
John
-----Original Message-----
From: cocoa-dev-bounces+john.darnell=<walsworth.com...>
[mailto:cocoa-dev-bounces+john.darnell=<walsworth.com...>] On
Behalf Of Jens Alfke
Sent: Thursday, May 15, 2008 9:07 PM
To: Joseph Ayers
Cc: <Cocoa-dev...>; mmalc crawford
Subject: Re: Guidance for Cocoa's steep learning curve
On 15 May '08, at 6:33 PM, Joseph Ayers wrote:
> What is absolutely
> baffling is dealing with NSTableView. The documentation absolutely
> sucks. How does one map table rows and columns
> on NSMutableArrays and NSMutableDictionaries. How does one map the
> Rows and Columns of a "dataSource"
> on a NSTable view?
I take it you read the table view programming guide and it didn't help?
file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.
CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/Co
nceptual/TableView/Tasks/UsingTableDataSource.html -
On Fri, May 16, 2008 at 9:30 PM, john darnell
<john.darnell...> wrote:
> I don't mean to be mean, but I agree with Joseph; most Apple
> documentation is really, really poor.
>
> *No, that's not correct.* The documentation is extensive, and
> comprehensive, but unless you already know what you are reading about,
> it might as well have been written in Farsi (no offense meant to any who
> speak Farsi--and if Farsi is your first language, then substitute
> English for Farsi).
>
> I have found this to be true on most every product's documentation; not
> just X Code. It is easily understood after five years of experience.
> The beginner struggles with the concepts, the locutions, the native
> phrases that the experienced programmer understands.
>
> For example, I was reading up on NSString yesterday and it began
> discussing "delegates." What the blazes is a delegate? (Please, no
> responses needed.) Open up any Developer page on the Apple site, and
> you run into the same thing. Concepts appear that are inadequately
> described, or described with so much jargon that even the experienced
> programmer (such as myself) has trouble making his way through it.
>
> Some of this might be better dealt with if the document were more
> extensively hyperlinked.
Massive hyperlinking would be nice, but you can make do without.
Google for "delegate site:developer.apple.com" and the first hit is
"Cocoa Fundamentals Guide: Delegates and Data Sources". This document
explains what delegates are and how to use them.
It's documentation, not a tutorial. It assumes you're relatively
fluent in the system as a whole, and doesn't try to teach you from
scratch. In other words, this is a feature, not a bug. I could
certainly see wanting more tutorials from Apple, but the documentation
itself does the job it's intended for pretty well. For now, if you're
after a tutorial, your best bet is probably to turn to third parties
in the form of Cocoa books.
Mike -
> I have found this to be true on most every product's documentation; not
> just X Code. It is easily understood after five years of experience.
> The beginner struggles with the concepts, the locutions, the native
> phrases that the experienced programmer understands.
I feel the need to chime in on this. I come from a very different
background than one would expect (if one read my posts to this list
regularly). I am entirely unschooled in this field and in some aspects
it shows very plainly. Yet I was writing production applications
within a few months. Some of which are still in use today with very
little changes. That would simply not have been possible without a)
the extensive and comparatively excellent documentation, b) a good API
reference browser (used to be CocoaBrowser, now I use AppKiDo - thanks
Andy Lee), and c) a few of the really good Cocoa books.
That said, the documentation is the reference manual. Let's
consider, though, why everything that comes with a huge manual also
spawns third-party books on the subject? Because anything that
complicated always needs a structured, "lesson-based" approach. That
is *NOT* the documentation's job. Not even the conceptual
documentation.
Your frustration is understandable (really, I felt a little lost in
the beginning too), but it most certainly does *NOT* take five years
to be able to effectively leverage the reference material available.
I apologize if this comes across as an attack (it's not meant as
such), but I find that assertion absurd. Had you said it takes five
years or so to become 'good at' Cocoa/Objective-C/XCode, I'd be less
inclined to object.
As an example, I know nothing of biology. Yet my current day job
consists of building and maintaining a Cocoa application used for
scientific research in the field of biology. I had no idea what a
'cytokine' was yet the specifications for the application I was to
design and build threw words like that around a lot. Wikipedia was my
friend, then "Bioinformatic for Dummies" (yes, I'm chuckling at myself
too, just having written that*). I'm still not a biologist nor will I
ever be, but it was up to me to do the research necessary.
* You think that's funny, you should've seen me presenting the beta
to biologists using an actual analysis. Though the application works
as advertised and has received nothing but glowing feedback, they had
a lot of questions I still couldn't answer.
> For example, I was reading up on NSString yesterday and it began
> discussing "delegates." What the blazes is a delegate? (Please, no
> responses needed.)
Like anything else that's highly technical, it's up to you to search
for definitions. Perhaps a universal glossary in the documentation
would help (file an enhancement request) but the very top of the main
Cocoa reference page lists the "Fundamentals" guide, which you are
meant to have read thoroughly. It contains this:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
/CocoaDesignPatterns/chapter_5_section_3.html#//apple_ref/doc/uid/TP4000297
4-CH6-SW19
... an in-depth explanation of this mechanism. You CANNOT blame the
documentation for using "jargon" if you don't bother to read the very
basic introductory material.
> Some of this might be better dealt with if the document were more
> extensively hyperlinked.
Agreed. See below.
> At least Apple is going through the motions of attempting to get
> feedback from its users with the questions added at the bottom of their
> documentation. I hope that some day it does some good.
That's simply not fair. "Going through the motions"? The
documentation is regularly (every few months) refined and expanded
upon. They're not simply 'going through the motions'. As a Cocoa
developer of more than five years, I can speak from experience when I
say they're doing far, far more than 'going through the motions'. Even
simple spelling mistakes or incorrect punctuation are fixed pretty
quickly by using that 'feedback' box at the bottom of the page. I
believe in credit where it is due - especially when floundering in a
room full of very bright scientists.
--
I.S. -
Sigh. Your attitude reminds me of a conversation I once had with a
fellow programmer. When I was encouraging her to add more documentation
to the code, she replied, jokingly, "If it was hard for me to write,
then it should be hard for them to read."
The sad thing is that you are not joking...
[Mike says:] >
Google for "delegate site:developer.apple.com" and the first hit is
"Cocoa Fundamentals Guide: Delegates and Data Sources". This document
explains what delegates are and how to use them.
It's documentation, not a tutorial. It assumes you're relatively
fluent in the system as a whole, and doesn't try to teach you from
scratch. In other words, this is a feature, not a bug. I could
certainly see wanting more tutorials from Apple, but the documentation
itself does the job it's intended for pretty well. For now, if you're
after a tutorial, your best bet is probably to turn to third parties
in the form of Cocoa books. -
> Sigh. Your attitude reminds me of a conversation I once had with a
> fellow programmer. When I was encouraging her to add more documentation
> to the code, she replied, jokingly, "If it was hard for me to write,
> then it should be hard for them to read."
>
> The sad thing is that you are not joking...
I don't think it's possible to continue a rational debate when you
keep going down this type of path. Nobody here even remotely suggested
that documentation should be hard to read. Conversely, nobody can
reasonably argue that it is possible for documentation (on such a
highly complex technical subject) to be made "easy".
--
I.S. -
On May 16, 2008, at 9:30 AM, john darnell wrote:
> I don't mean to be mean, but I agree with Joseph; most Apple
> documentation is really, really poor.
>
> *No, that's not correct.* The documentation is extensive, and
> comprehensive, but unless you already know what you are reading about,
> it might as well have been written in Farsi (no offense meant to any
> who
> speak Farsi--and if Farsi is your first language, then substitute
> English for Farsi).
I'm curious what you're actually looking for in documentation; what
you think Apple or Microsoft could do to make them better, because I'm
having trouble accepting this premise and it seems to me that what you
want is simply unrealistic. If they were able to make documentation
that made you happy, my guess is that the most of us would hate it,
because we'd have to slog through fundamental conceptual information
in places where it doesn't belong.
I am not as familiar with Microsoft's documentation, but my limited
experience with it has been fairly positive (as much as I hate to say
anything good about Microsoft ;) ) and I find the Apple documentation
to be excellent. There have been times where the documentation has
lagged behind development and caused some difficulties for developers,
especially in the early days of OS X, but overall, I think we are
spoiled by the amount of information we have available to us.
Personally, I think that the "Object-Oriented Programming with
Objective-C" book on the developer website, which isn't all that
changed from the NeXT days, contains one of the clearest explanations
of the concepts underlying object-oriented programming that I've seen
anywhere, and it is right where it belongs - that type of conceptual
material doesn't belong in the API documentation.
Hand-holding guides exist; they're called books. Apple even offers
several guides to conceptual information, but they are separate from
the API documentation. Although I think a reasonably intelligent
person could learn everything they needed to know from Apple's
official documentation without using other books, those other books
clearly exist for a reason, which is to shorten the learning curve a
bit and gather up a lot of disparate information into one place. Like
I. Savant, my educational background is not in programming, and I am
pretty much self taught, so believe me, I understand the challenges of
learning this stuff. You have to acquire the foundational knowledge,
either from the Apple documentation, or from third-party books. You
can't just expect to look at tiny pieces of the puzzle like the API
documentation of a class and expect to magically get the big picture
from it.
Documentation isn't magic. It can't be all things to all people.
Considering the complexity and the target audience, I'd say that
Apple's documentation is, frankly, stellar. Yes, often understanding
one part will require you to do some research to understand a term or
concept from another part of the system, or to sit down for a few
hours and experiment, or maybe even ask a few questions here. If it
could be made so simple that none of that was necessary (without
sacrificing functionality), most of the people on this list would be
out of a job or, at least, making less money. Too many people assume
programming is (or should be) easier than it really is. -
On Fri, May 16, 2008 at 10:19 PM, john darnell
<john.darnell...> wrote:
>
> Sigh. Your attitude reminds me of a conversation I once had with a
> fellow programmer. When I was encouraging her to add more documentation
> to the code, she replied, jokingly, "If it was hard for me to write,
> then it should be hard for them to read."
>
> The sad thing is that you are not joking...
I don't think you quite understood what I'm getting at.
Apple's documentation does its job quite well. The "problem" with it,
such as it is, is that it is not a tutorial. If you're learning a
system from scratch, you don't want and can't really use straight-up
documentation, you want a tutorial.
Apple's tutorials pretty much stink. They're short and quick and cover
very little. This is an area where they lack quite a bit and, luckly,
third parties have leapt in to cover the hole. If you're having
trouble getting up to speed then it is this lack which is getting you.
But it is unreasonable to expect the NSString reference documentation
to cover basic concepts about the framework. That's not what reference
documentation is for.
Mike -
On 16 May '08, at 7:19 AM, john darnell wrote:
> Sigh. Your attitude reminds me of a conversation I once had with a
> fellow programmer. When I was encouraging her to add more
> documentation
> to the code, she replied, jokingly, "If it was hard for me to write,
> then it should be hard for them to read."
> The sad thing is that you are not joking...
OK, this is getting somewhat offensive. Most of Apple's developer
documentation is written by full-time tech writers, with extensive
consultation and review from the engineers involved in the code. I
know some of these writers, and I've been involved in many doc
planning and review meetings over the years.
Any deficiencies in clarity or accuracy are the result of a simple
lack of time or resources. To assume that they're somehow deliberate
is a symptom of the common engineer arrogance that assumes that any
problem you're not directly involved in solving is "trivial" and that
its persistence is only due to incompetence or maliciousness. That is
a bullshit attitude. Don't perpetuate it.
Face it: programming is hard. Programming very sophisticated complex
things like GUIs is very hard. Frameworks make that job a lot less
hard [if you doubt this, go and read the old '80s "Inside Mac" I...V
sometime!], but there are still a lot of concepts and details to
learn, and many times their topology does not reduce to a directed
acyclic graph (i.e. you can't present them in order without forward
references.)
Also face it: Most of the other software docs in the world are much
harder to follow, because most companies/projects can't afford to pay
full-time tech writers. There are a lot of amazing open source
libraries, but for the most part you are going to have to put some
serious effort into figuring out how to use them. That's not (usually)
because anyone deliberately made them hard to follow; it's just part
of the territory. We are programmers because we are good at figuring
out and navigating through complex abstract systems.
Apple's docs are very good these days, but they're not pitched at the
level of "Cocoa 4 Teh Dummiez!!1". That's not Apple's job. There are
enough 3rd party Cocoa books by now that I'm sure there are ones at
that level; anyone finding the Apple docs inadequate should go look
into these. (Yes, this might require spending some money. Deal with
it. We all got into computer programming to make the big bucks, right?)
—Jens -
To set the record straight, I am going through two Cocoa books as we
speak. (FYI, the books are O'Reilly's "Cocoa with Objective-C" and
Hillegass' "Cocoa Programming for Mac OSX") I, too recognize the value
of outside tutorials. I would point out that both books encourage the
programmer to read the references, but I'm not sure that you would get
the point, so let it pass.
And, what I hear from this august crowd is a consensus that the
references are difficult to understand, but necessarily so--that they
ought to be that way. This is a debate that has been going on since I
bought my first CP/M computer back in the early eighties. I doubt we
will resolve it here. I certainly have no intention of changing my
mind.
But I also hear from you all a willingness to help me, a newbie with all
sorts of newbie questions, figure out Cocoa, despite our differences.
That, I find gratifying.
I recommend we discontinue this discussion, and move on to that part
where I ask good, pointed questions about how to make Cocoa work.
You're all good people who are trying to convince someone who is part
Irish and part German and thoroughly stubborn.
Thanks for the lively discussion.
John
-----Original Message-----
From: cocoa-dev-bounces+john.darnell=<walsworth.com...>
[mailto:cocoa-dev-bounces+john.darnell=<walsworth.com...>] On
Behalf Of Michael Ash
Sent: Friday, May 16, 2008 9:32 AM
To: Cocoa Developers
Subject: Re: Guidance for Cocoa's steep learning curve
On Fri, May 16, 2008 at 10:19 PM, john darnell
<john.darnell...> wrote:
>documentation
> Sigh. Your attitude reminds me of a conversation I once had with a
> fellow programmer. When I was encouraging her to add more
> to the code, she replied, jokingly, "If it was hard for me to write,
> then it should be hard for them to read."
>
> The sad thing is that you are not joking...
I don't think you quite understood what I'm getting at.
Apple's documentation does its job quite well. The "problem" with it,
such as it is, is that it is not a tutorial. If you're learning a
system from scratch, you don't want and can't really use straight-up
documentation, you want a tutorial.
Apple's tutorials pretty much stink. They're short and quick and cover
very little. This is an area where they lack quite a bit and, luckly,
third parties have leapt in to cover the hole. If you're having
trouble getting up to speed then it is this lack which is getting you.
But it is unreasonable to expect the NSString reference documentation
to cover basic concepts about the framework. That's not what reference
documentation is for.
Mike -
> And, what I hear from this august crowd is a consensus that the
> references are difficult to understand, but necessarily so--that they
> ought to be that way. This is a debate that has been going on since I
> bought my first CP/M computer back in the early eighties. I doubt we
> will resolve it here. I certainly have no intention of changing my
> mind.
ACK! For the love of all that's holy, hear my plea: NOBODY SAID OR
IMPLIED ANY SUCH THING! If you believe otherwise, please point out the
exact text.
> But I also hear from you all a willingness to help me, a newbie with all
> sorts of newbie questions, figure out Cocoa, despite our differences.
> That, I find gratifying.
Absolutely! It's just that your complaint that "it's difficult"
falls on deaf ears. We all know that (not really the documentation -
it's hard because it's a vast, complex subject and no amount of
refinement will make that go away completely). That's why this very
mailing list exists. And the books. And the online tutorials. And the
cocoadev wiki ... etc.
Post your pointed questions and we'll all do our best to help. That
much should be obvious from the traffic. If you have specific
suggestions for making the documentation better, submit them. If the
majority agrees, they'll submit those same suggestions ... and they
*will* get implemented. Believe that.
> You're all good people who are trying to convince someone who is part
> Irish and part German and thoroughly stubborn.
Irrelevant, but understood. ;-)
--
I.S. -
Tutorial examples don't really belong in API docs. Their ultimate
goal is to state the purpose and usage as directly as possible so the
developer can get what they need and move on. Continuously sifting
through tutorial information and examples would be quite tedious and
redundant for the majority who already understand the general concepts
and conventions.
Apple does provide many introductory and advanced "booklets" that help
to grasp the concepts and conventions. Once you learn these and put
everything together a lot of the APIs make sense, mostly because of
Apple's adherence to these concepts and conventions (especially with
Cocoa).
Some of the booklets take a little extra looking to find and may
contain redundant or seemingly irrelevant information to what you're
looking for. But I've found that continuing to read on would produce
little gems, or pieces of the puzzle if you will, that spark
connections for you that you previously didn't make before.
Apple's tutorials are meant to be used as samples of applying the
concepts you've read in the booklets. You know the lingo and basic
idea, now you get to see how it's applied in real examples. If you
haven't yet learned the idea concepts, the code tutorials won't do
much for you. You'll see what code is needed to carry out a certain
task, but you won't know why the code was done as it is and won't
recognize the application of the concepts and conventions. The
tutorial would be mostly fruitless.
Several books have been written that take different approaches to
teaching the concepts and showing their applications. Not everyone
will learn from the exact same approach, and I don't believe it's
possible to make a single approach that works for everyone. Apple
presents one approach and it won't work for everyone, and when it
doesn't work for you, you search for different approaches.
Back in the college days I had taken two different courses on object
oriented programming at two different universities. Both books were
400 pages+. And sadly I still didn't quite understand the
relationship of objects and classes and why anyone would need many
copies (objects) of something made up of one group of code (a class).
I had come from a procedural background and had a procedural mindset.
Then one day I got desperate and bought an online course presented in
Shockwave. It took me 3 days to complete the course. Not because it
was short, but so much was making sense and I was making so many
connections that I couldn't stop and would work at it for 12-15 hours
each day. Afterwards OO programing made complete sense and I
understood its purpose and possibilities. For some reason that
particular approach was just what I needed.
I don't blame the college courses nor do I think they were bad or
worthless; They just weren't for me. Apple's approach is not for
everyone either but that doesn't invalidate its value. I personally
found it extremely helpful.
On May 16, 2008, at 8:27 AM, I. Savant wrote:
> I don't think it's possible to continue a rational debate when you
> keep going down this type of path. Nobody here even remotely suggested
> that documentation should be hard to read. Conversely, nobody can
> reasonably argue that it is possible for documentation (on such a
> highly complex technical subject) to be made "easy".
-
On May 16, 2008, at 10:50 AM, Jens Alfke wrote:
> but there are still a lot of concepts and details to learn, and many
> times their topology does not reduce to a directed acyclic graph
> (i.e. you can't present them in order without forward references.)
Jens, I was going to bring up the concept of forward references, but I
ran off to run an errand and now I find you beat me to it. ;)
I think this gets at what a lot of people complain about when they
feel overwhelmed by the things they need to learn to start developing
with Cocoa. (There's also the issue of people trying to do too much
too soon, as has been mentioned, but that's a separate discussion.)
Forward references are what the concepts docs are for, but for some
reason, they don't seem to be serving that purpose for some people.
I'm not sure why.
With the rapidly increasing popularity of Cocoa development (as
evidenced by the sold-out WWDC), I wonder if the market for Cocoa
instruction will grow as well. I don't just mean more books, as
welcome as those will be. I feel like introductory Cocoa is the sort
of thing where face-to-face instruction makes a huge difference. I
can imagine someone taking the road maps that Erik Buck started this
thread with (a pretty good pass at linearizing the DAG, IMO) and
building a curriculum around them. This could be used in a Continuing
Education course, or in an after-work study program like some
companies have. People could offer video courses too.
--Andy -
> Forward references are what the concepts docs are for, but for some
> reason, they don't seem to be serving that purpose for some people.
> I'm not sure why.
I get the feeling that some people never notice the "Companion Guides"
section at the top of the class references. They're right there at the top;
I don't know what Apple could do to make them more obvious. But much of the
discussion re docs seems to indicate that some people remain totally unaware
of these guides...
--
Scott Ribe
<scott_ribe...>
http://www.killerbytes.com/
(303) 722-0567 voice -
On Fri, May 16, 2008 at 11:22 AM, Scott Ribe <scott_ribe...> wrote:
>> Forward references are what the concepts docs are for, but for some
>> reason, they don't seem to be serving that purpose for some people.
>> I'm not sure why.
>
> I get the feeling that some people never notice the "Companion Guides"
> section at the top of the class references. They're right there at the top;
> I don't know what Apple could do to make them more obvious. But much of the
> discussion re docs seems to indicate that some people remain totally unaware
> of these guides...
Yeah I get that feeling as well... The conceptual documentation is
good and has been getting better and better. Also the getting starting
docs lead you down the paths you need to follow. Not sure how to get
folks to find the information that is in front of them. I guess folks
are a little impatient and don't want to read things closely enough...
IMHO grab a book or two, hit up http://www.cocoadevcentral.com/ (etc.)
and MOST IMPORTANTLY read the getting started and conceptual
documentation in all of the areas that the book and online tutorials
touch on.
More often then not when someone asks a question on this list I am
able to type a few words into google scoped to Apple's developer site
and hit on the conceptual docs that I can then link to help answer the
question. So I find the information exists and is usually more then
sufficient (when not I file feedback).
-Shawn -
On Fri, May 16, 2008 at 10:57 PM, john darnell
<john.darnell...> wrote:
> And, what I hear from this august crowd is a consensus that the
> references are difficult to understand, but necessarily so--that they
> ought to be that way.
That's not really it. It's not that they should be difficult to
understand. Indeed they *aren't* difficult to understand... once you
have all of the prerequisite knowledge. And yes, having all of the
prerequisite knowledge presents a pretty big chicken-and-egg problem
when you're coming at the reference documentation fresh off the
street, as it were. But since they aren't intended for that situation,
that's to be expected.
Imagine picking up a dictionary for a foreign language you don't
speak, say, French. (If you speak French, imaginez une autre langue.)
This dictionary is going to be essentially useless for you. Every word
is defined in terms of *other* French words! Even if you can somehow
slog through that, it still won't teach you all the grammar concepts
you need to know. It may have definitions for the words "verb" and
"noun" but it's not going to give you conjugation rules or explain
finer points of grammar.
And yet this very same dictionary will be quite handy for someone who
speaks French. That it's useless for you, a non-speaker, doesn't mean
there's anything wrong with it, you're just using the wrong tool. You
want a book on learning French. Once you get up to speed to where you
can speak and understand the basics of the language, the dictionary
will become extremely useful. Until then, looking for help in the
dictionary is the wrong move.
So it is with Cocoa. If you don't know what a delegate is, the
reference documentation is the wrong place to find out.
Mike -
> Imagine picking up a dictionary for a foreign language you don't
> speak
That is a very good analogy. For my situation I would take it even a
step further....
<analogy>
Let's say I am fluent in Italian and Spanish already. I've even had
one year of French in school.
I am bored to death going through tutorials that try to teach me
"Hello, my name is Torsten. What's your name?". On the other hand:
whenever I want to write an sophisticated article - I get stuck. While
I can look up individual words, I missing the proper phrases. Phrases
are hard to teach. (And btw: hard to search for) You need to have
proper conversations to learn them. What is so particular frustrating
is that I am fluent in all these other languages. This makes hitting
the wall when writing in French even more frustrating.
So the dictionary we got is of awesome quality. The introductionary
tutorials are great to order some food in a restaurant. But when you
want to write an article in French - you get stuck. I just don't know
any people that speak french so I can meat up with them and learn some
phrases (yet). [2][3] While reading helps a lot, personal
communication is much faster. And knowing all these other languages by
heart makes me even more impatient. I would rather concentrate on the
content of the article than the language.
IMO there is huge gap to fill between "My name is Torsten" and
something from Victor Hugo [1]
</analogy>
I'll surely will do my share in helping out others while learning. I
would not even blame Apple. Just stating the fact that (while it's
getting better) some things are just missing. Or not obvious to find
as a newbie. Looking at code helps a lot. I try to look into open
source projects to see how people are doing things. But it's hard.
Hard to find a the project/example to look at. And sometimes hard to
get into the code base (if you -as a newbie- ever had a look into
Adium you know what I mean)
Anyway!
cheers
--
Torsten
[1] http://en.wikipedia.org/wiki/Victor_Hugo
[2] http://vafer.org/blog/20080515154119
[3] http://vafer.org/blog/20080424190102 -
On Sat, May 17, 2008 at 5:53 PM, Torsten Curdt <tcurdt...> wrote:
>> Imagine picking up a dictionary for a foreign language you don't
>> speak
>
> That is a very good analogy. For my situation I would take it even a step
> further....
>
> <analogy>
> Let's say I am fluent in Italian and Spanish already. I've even had one year
> of French in school.
>
> I am bored to death going through tutorials that try to teach me "Hello, my
> name is Torsten. What's your name?". On the other hand: whenever I want to
> write an sophisticated article - I get stuck. While I can look up individual
> words, I missing the proper phrases. Phrases are hard to teach. (And btw:
> hard to search for) You need to have proper conversations to learn them.
> What is so particular frustrating is that I am fluent in all these other
> languages. This makes hitting the wall when writing in French even more
> frustrating.
I agree with this, and I think a lot of people end up getting stuck at
this intermediate stage. Apple has a great "dictionary" and they have
decent "My name is Bob" material. They have little quality material in
the middle. This is where the books fill in. Personally speaking I
spent a lot of time at this middle stage before finally graduating,
mostly through sheer force of will.
There's definitely room for improvement here. My only point is that
the NSString class documentation is the wrong place for it to happen.
Mike -
> I agree with this, and I think a lot of people end up getting stuck at
> this intermediate stage. Apple has a great "dictionary" and they have
> decent "My name is Bob" material. They have little quality material in
> the middle. This is where the books fill in. Personally speaking I
> spent a lot of time at this middle stage before finally graduating,
> mostly through sheer force of will.
>
> There's definitely room for improvement here. My only point is that
> the NSString class documentation is the wrong place for it to happen.
+1 absolutely!
cheers
--
Torsten -
-----Original Message-----
From: cocoa-dev-bounces+john.darnell=<walsworth.com...>
[mailto:cocoa-dev-bounces+john.darnell=<walsworth.com...>] On
Behalf Of Michael Ash
Sent: Saturday, May 17, 2008 1:56 AM
To: Cocoa Developers
Subject: Re: Guidance for Cocoa's steep learning curve
On Fri, May 16, 2008 at 10:57 PM, john darnell
<john.darnell...> wrote:
> And, what I hear from this august crowd is a consensus that the
> references are difficult to understand, but necessarily so--that they
> ought to be that way.
That's not really it.
[John Darnell says:]
Please, Mr. Ash. No more. I publicly admitted how incorrect my opinion
was after I was clued in on the existence of companions. They fulfill
all the requirements I was looking for in a piece of documentation.
Let's move on to some other topic.
R,
John -
That's the best roadmap I've ever seen.
On May 14, 2008, at 6:19 PM, Erik Buck wrote:
>
> The obstacles, misconceptions, and prerequisite concepts that need
> to be mastered when learning Cocoa vary dramatically based on the
> past experience of the learner. I am a very experienced Cocoa
> programmer. I am also an author of the thickest Cocoa Programming
> book and have another Cocoa book due out real soon. I have some
> guidance.
>
> To relate my background, I started using NeXTstep (the precursor to
> Cocoa) that included Interface Builder and Objective-C and App Kit
> in late 1988. I had heard of object oriented programming but didn't
> "get it". I had attended a one day seminar on "C with Classes"
> which later became C++. I left the seminar no wiser than when I
> arrived. I had worked for eight years with C and a variety of
> assembly languages. I had been using Ada for a year.
>
> I became excited about NeXTstep software development, worked on many
> hobby projects, and from 1991 on I worked extensively with NeXTstep/
> Openstep/YelowBox/Cocoa as well as C++ and many other technologies.
> I founded a company in the early 90s and developed an industry
> leading application. I sold the intellectual property to a Fortune
> 500 company in 1996, and my company continued to work in the
> industry until late 2002. I am now "Senior Staff" for a different
> Fortune 500 company in a related industry.
>
> Here is my guidance based on some arbitrarily chosen categories of
> learners:
>
> === If you have never programmed before
> 1) Learn any programming language (it may seem hard, but every
> 'real' programmer knows many languages and you have to start
> somewhere)
> 2) Learn C and at least learn to recognize low level operations like
> bit manipulation, pointers, intrinsic types, pointers to pointers,
> pointers to functions, etc. Without this, you will be lost and
> dangerous when writing Cocoa programs in Objective-C.
> 3) Learn Objective-C. It takes about 1 day for an experienced C
> programmer.
> 4) Start the long process of learning the Cocoa frameworks, the C
> standard library, and some of the Unix libraries.
> 4A) Learn Cocoa conventions and common patterns. These are not
> optional. Clear understanding of the following is required to write
> graphical Cocoa applications: two stage allocation and
> initialization, designated initializers, memory management,
> selectors, dynamic messaging, accessors, the responder chain,
> delegates, target/action, data sources, archiving & unarchiving
> (e.g. freeze dried objects in .nib files), the view hierarchy, key
> and main windows, and above all the Model View Controller pattern.
> 4B) Study Apple's sample applications, work tutorials, experiment,
> and build a few hobby projects.
>
> === If you are primarily an experienced "dynamic" language
> programmer (perl, Ruby, Python, Smalltalk, TCL, etc)
> 1) Learn C and at least learn to recognize low level operations like
> bit manipulation, pointers, intrinsic types, pointers to pointers,
> pointers to functions, etc. Without this, you will be lost and
> dangerous when writing Cocoa programs in Objective-C.
> 2) Learn why C and therefore Objective C use a pre-processor with
> separate headers and separate implementation files. Come to grips
> with the edit, COMPILE, link, debug cycle.
> 3) Learn Objective-C. It takes about 1 day. You will realize the
> Objective-C is very dynamic and flexible but has its own idioms.
> 4) Start the long process of learning the Cocoa frameworks, the C
> standard library, and some of the Unix libraries.
> 4A) Learn Cocoa conventions and common patterns. Many will be
> familiar to a Smalltalk programmer. These are not optional. Clear
> understanding of the following is required to write graphical Cocoa
> applications: two stage allocation and initialization, designated
> initializers, memory management, selectors, dynamic messaging,
> accessors, the responder chain, delegates, target/action, data
> sources, archiving & unarchiving (e.g. freeze dried objects in .nib
> files), the view hierarchy, key and main windows, and above all the
> Model View Controller pattern.
> 4B) Study Apple's sample applications, work tutorials, experiment,
> and build a few hobby projects.
> 4C) If you object to Cocoa's memory management conventions, learn to
> love them because in the world of C, automatic garbage collection
> can not solve all of your problems.
>
> === If you are primarily an experienced C++ programmer (In my
> experience you will have the hardest time)
> 1) Forget everything you think you know about Object Oriented
> programming (no offense intended).
> 2) Break every ingrained C++ habit and idiom because the design
> philosophy of Objective-C and Cocoa is exactly the opposite of
> almost everything C++ encourages.
> 3) Learn Objective-C. It takes about 1 day for an experienced C
> programmer. You will realize the Objective-C is very dynamic an
> flexible. Many patterns and idioms in C++ are unneeded in Objective-
> C. Objective-C classes tend to be more high level and straight
> forward, and you tend to use fewer of them. You may feel
> disoriented without the accustomed "bondage and Discipline" [http://c2.com/cgi/wiki?BondageAndDisciplineLanguage
> ], but I strongly advise you to learn an appreciation for freedom
> and the flexibility to send any message to any object even if the
> receiver did not exist when your application was compiled and
> linked. For many, an appreciation for Cocoa's undo mechanism breaks
> the ice. (although dynamism is ubiquitous in Cocoa)
> 4) Start the long process of learning the Cocoa frameworks.
> 4A) Learn Cocoa conventions and common patterns. These are not
> optional. Clear understanding of the following is required to write
> graphical Cocoa applications: two stage allocation and
> initialization, designated initializers, memory management,
> selectors, dynamic messaging, accessors, the responder chain,
> delegates, target/action, data sources, archiving & unarchiving
> (e.g. freeze dried objects in .nib files), the view hierarchy, key
> and main windows, and above all the Model View Controller pattern.
> 4B) Study Apple's sample applications, work tutorials, experiment,
> and build a few hobby projects.
>
>
> === If you are primarily a Java programmer
> 1) Learn Objective-C. It takes about 1 day. You will realize the
> Objective-C is very dynamic and flexible. Many patterns and idioms
> in Java and C# are unneeded in Objective-C. You may feel
> disoriented without the accustomed "bondage and Discipline"[http://c2.com/cgi/wiki?BondageAndDisciplineLanguage
> ], but I strongly advise you to learn an appreciation for freedom
> and the flexibility to send any message to any object.
> 2) Start the long process of learning the Cocoa frameworks, the C
> standard library, and some of the Unix libraries.
> 2A) Learn Cocoa conventions and common patterns. These are not
> optional. Clear understanding of the following is required to write
> graphical Cocoa applications: two stage allocation and
> initialization, designated initializers, memory management,
> selectors, dynamic messaging, accessors, the responder chain,
> delegates, target/action, data sources, archiving & unarchiving
> (e.g. freeze dried objects in .nib files), the view hierarchy, key
> and main windows, and above all the Model View Controller pattern.
> 2B) Study Apple's sample applications, work tutorials, experiment,
> and build a few hobby projects.
>
>
> === All
> Once you understand in principal how all of the basic Cocoa patterns
> are implemented, learn about Key Value Observing, Bindings, Core
> Data, etc. These use advanced patterns that seem like magic until
> you have mastered the basics.
-
Yes.
For detailed guidance, buy Aaron Hillegass's book Cocoa Programming
for Mac OS X, and go through it from beginning to end, doing every
exercise and every challenge. I have done that with the first two
editions and am about to do it with the third, and I promise you it's
a good way to learn and re-learn Cocoa. Based on that I'm now
gainfully employed writing an iPhone application.
On May 15, 2008, at 6:06 PM, Jens Alfke wrote:
>
> On 15 May '08, at 5:03 PM, mmalc crawford wrote:
>
>> My guidance for Cocoa's alleged "steep learning curve" is, "Why are
>> you making it steep?"
>> It reminds me of the clichéd joke: "Doctor, it hurts when I do
>> this." "Well, don't do that."
>
> I agree. There are so many questions on this list from people who
> are clearly Cocoa newbies, who are trying to do really difficult/
> advanced things.
>
> If you're learning Cocoa, just write something straightforward like
> a simple app, like the CurrencyConverter or whatever. Learn the
> basics of how to write action methods, wire up an interface in IB,
> and do basic things with Foundation classes. Add features one at a
> time ... documents, copy and paste, drag and drop, whatever. Just
> don't try to start out all at once with CoreData and XML and
> AppleScript and accessing other apps' windows!
>
> —Jens
