The Daydream Blog

Unlearning Cocoa

Note this article is intended for developers and may be of limited interest to our wider client base.

Kevin Hoffman has given a critique of the now infamous criticism of iPhone development. (Another Microsoft Developer Falls Victim to Framework Myopia [The .NET Addict's Blog])

The key points in Kevin’s post are his explanation of how experienced Windows developers should handle their migration to Mac or iPhone development. It reminded me of a post I’ve been planning to write for a long time that most easily be summarised as:

To learn Cocoa, you must un-learn your past development experience.

Cocoa assumes an MVC paradigm. Interface Builder and NIB’s are very weird compared to other approaches. The frameworks are heavily designed for sub-classing to create your own behaviour, rather than having lots of settings to tweak behaviour.

Every time you try to learn a new aspect of Cocoa, you find yourself struggling to do something that feels like the “right way”. A few days later you come out with 3 lines of code that feel completely natural but felt incredibly painful to reach. You will be met with countless, “aaah, that’s how it works and it makes complete sense” moments. You spend days wondering why this bit of Cocoa is so gnarly, and seemingly unintuitive, until you reach another moment of understanding.

People often say that Cocoa has a steep learning curve. It does not. It has a steep un-learning curve, followed by a gentle re-learning curve. Getting yourself out of your previous development mind set can make the whole experience a lot more pleasant.

What is disappointing is that none of the documentation or tutorials spend much time comparing and contrasting with other approaches, that would make the process of unlearning easier.

7 Responses to “Unlearning Cocoa”

  1. Jason Says:

    “The frameworks are heavily designed for sub-classing to create your own behaviour, rather than having lots of settings to tweak behaviour.”

    I would disagree and say that almost all tweaking is done using delegates, not subclassing. The exception being custom drawing buy subclassing NSView

  2. Jamie Says:

    “It has a steep un-learning curve” - I’d definitely agree that this is true. Unfortunately, a lot of people seem unwilling to unlearn what they know, and end up fighting against the frameworks (and, indeed, the language) instead of embracing them. Of course, they end up hating the system as a result (and thinking those of us who like it to be crazy).

    For some, I think the reason that they don’t want to unlearn what they know is that they actually do realise that, if they do this, they’ll have to spend even more time learning the ‘new way’. It’s much easier just to dismiss the ‘new way’ as crazy and go back to what you know.

  3. warren Says:

    I disagree completely. I have more than Windows and Mac experience. The Cocoa framework is well designed, but is a second generation framework, and the complete tool set that Apple provides, is not well integrated. You get a totally “NON-RAD” IDE, a separate dialog box editing tool that has extremely crappy code generation capabilities, and a really great set of documentation to a framework that you don’t have the full source code to. It’s darn good that the framework comes with good documentation, because Apple has decided not to give Apple developers access to the source code to the framework that they rely on.

    There are many tradeoffs, weaknesses, and downright bizarre subtleties in learning Cocoa, and it does indeed have a very steep learning curve. Add in reference counting (if you use it) and garbage collection (if you use it), and the absolutely maddening “silent failures” that come as part at parcel of the Objective C messaging system — you can send a message to a nil object, it does nothing, and does it quietly — these are all part of what those of us with more than 2 platforms under our belt knowingly include in our estimation of the total learning curve of the platform.

    You may love and understand and accept XCode+Cocoa+ObjectiveC, and thus you are completely biased. Take someone who has Linux/Unix, Windows, and multiple frameworks and multiple types of development (from non visual up to rich client, and web experience) but zero Objective C, and zero Cocoa/NextStep experience, and there is indeed a very steep learning curve.

    Learning and unlearning are two words for the exact same thing. We could drop both words and say, and use an aquarium term here; Moving a fish from a tank with one extreme water chemistry, to another tank with extreme water chemistry causes stress on the fish. Moving from procedural to object oriented, from something rather more ad-hoc to something rather more like MVC, these all involve both learning and unlearning various habits. Only a completely mac-centric snob would pretend that every other set of standards, rules and ideas for every other platform are inherently “worse”, and that thus, learning Mac was easy, except for unlearning all the “damage” done to you by every other tool on the planet.

    W

  4. rsfinn Says:

    Describing Interface Builder as “a separate dialog box editing tool that has extremely crappy code generation capabilities” shows that you’ve missed the point of Interface Builder.

    “You may love and understand and accept XCode+Cocoa+ObjectiveC, and thus you are completely biased” — but if you hate and fear it, you’re completely unbiased and objective? Nonsense.

    “Take someone who has … zero Cocoa/NextStep experience, and there is indeed a very steep learning curve.” Compared to someone who “understands” Cocoa? Well, yes; that’s very insightful of you.

    “Only a completely mac-centric snob would pretend that every other set of standards, rules and ideas for every other platform are inherently ‘worse’” — Paging Artie McStrawman…

    Seriously, you make some good points, once the reader gets past the attitude. For many people whose background is in other programming environments, Cocoa is indeed a challenge to learn. For some, who have waited years to find an environment that more closely matches their own mental model of how programming should be, Cocoa is like a breath of fresh air — and *those* people are going to thrive in the new environment, while the others struggle.

  5. Sanjay Samani Says:

    @warren, I didn’t describe “every other set of standards, rules and ideas for every other platform [as] inherently ‘worse’”. On the contrary, I have often argued that Apple could do much more to learn from other development tool chains.

    My point was that to learn Cocoa, you have to put aside your past experience and approach it fresh. If you expect Cocoa to work in a particular way, you often find yourself struggling and frustrated. When you do understand how something works, it is often easy, sensible, clean and self consistent, just different from what you might have expected. Therefore, putting aside your past experience makes the Cocoa learning process easier.

    I am not trying to argue whether one method is better than the other.

    As to your specific points, I would suggest you read Kevin Hoffman’s post linked at the top of the article, as he has experience with “Windows, and multiple frameworks and multiple types of development” and tackles many of the points you raise from a perspective that you may appreciate.

  6. warren Says:

    I agree with every positive point made about Cocoa.

    The only point I am whole-heartedly disagreeing is this one:

    “…. It does not. ”

    Every time I’ve forced myself to unlearn a bunch of habits that served me well in one place, and relearn a different set of habits, I have been richly rewarded.

    But “no learning curve”? Puh-leeze.

    Warren

  7. Cocoa Nut » Unlearning Cocoa Says:

    [...] the whole post here. Share and [...]

Leave a Reply

 
Site by Line