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 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
  • 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 and
    > columns on NSMutableArrays and NSMutableDictionaries. How does one
    > map the Rows and Columns of a "dataSource" on a NSTable view?
    >
    And here's another increasingly prevalent problem: a claim that the
    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:
    >
    > 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
  • > 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
previous month may 2008 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today