Theocacao: Cocoa Learning Curve

Cocoa Learning Curve

I received an email today from a new Cocoa programmer who said he enjoyed the Cocoa Dev Central tutorials, but had a bit of a hard time wrapping his head around the whole thing. He thought this might have something to do with the fact that he's fifteen, but age has nothing to do with it.

There is a Cocoa learning curve, just as in any programming environment. Some parts of Mac programming are easier than others, and sometimes you can end up with code which technically does the job but there's a sense that it's not necessarily the "right way." All of this is normal.

Again, it's not an age thing. Even people who have been writing software for decades encounter some conceptual stumbling blocks when first coming to Cocoa, but it does level out eventually. There are a few things to do to get to that plateau faster:

Always have at least one specific project to be working on. It's not interesting to learn new techniques in the abstract. If you have a practical reason for learning how to use something — such as users waiting for a feature — you'll be motivated to learn it. The "thank you" from your users is often the emotional payoff.

Do the remedial tutorials over and over again until you can do them in your sleep. Until you know it so well that you don't even need to glance at the directions, you're still learning something. Keep doing it, even if you think it's too basic.

Do whatever you can to expose yourself to other people working on Mac apps. A two- or three-person team for an app is great, as is going to WWDC or CocoaHeads/Xcoders. You learn about both code and the process of writing software. Mailing lists are also good for this.

The most important thing is to keep writing code. If you have an Cocoa book in-hand, don't feel you have to read the entire book before you go off writing software on your own. There are no rules. If you get inspired, go work on an app, even if it's just for a few days. If you get stuck, you can look things up on ADC or ask questions on cocoa-dev or macosx-dev.

Also, I hear nothing but good things about Big Nerd Ranch. It's complete immersion for a full week, away from all distractions.

Cocoa Learning Curve
Posted Jun 5, 2007 — 13 comments below

Chris Ryland — Jun 05, 07 4218

I second the Big Nerd Ranch recommendation—great people and great course.

The only caveat is that you really have to be ready to use what you learn immediately, at least part-time, or you'll lose it.

I took the course about 3 years ago, and had to restart almost from scratch when I started serious Cocoa development earlier this year.

Joe Goh — Jun 05, 07 4219

I'd like to add four more pieces of advice based on my personal experience learning Cocoa over the past year while writing my app.

4. Slow down. Take your time when learning new Cocoa technologies (like Core Data and Bindings), and don't get disheartened when you run into edge cases or somehow just can't get things to work for your project. Getting it done properly now will pay off in the future.

5. Don't be afraid to look around. If it seems like what you're doing is a whole load of work, take a breather and look at whether there are existing classes/frameworks/libraries that may already solve your problem.

6. When you're stuck, in doubt, or you feel like what you're doing just doesn't seem right, dive in and consult the documentation. The official documentation may be hard to navigate at times, and there seems to be way too much to read sometimes, but it all pays off in the long-run when you take the time to absorb it.

7. If you're still stuck, first search the mailing lists or Google for it. You may find that there are others out there who have hit the same problems you have. If there isn't, don't be afraid to ask on the mailing lists that Scott has mentioned.

Dave Ramsey — Jun 05, 07 4221

My favorite set of tutorials (I have not run the Cocoa Dev Central progression) was the O'Reilly tutorials at MacDevCenter. Scroll all the way to the bottom, and start working your way up. Of course, I never actually made it much past the 6th or 7th tutorial before I spun off on my own and started working on *my* project. That was all it took before Cocoa made sense, and I could start getting something out of Apple's documentation myself.

Frdric Hahn — Jun 05, 07 4222

CocoaDev Central is a great initiative to get useful information about specific Cocoa programming topics.

I also found a great tutorial to Xcode & Cocoa for absolute beginners on CocoaLab.com : CocoaLab / Become an Xcoder

I highly recommend this site to anyone who's a little bit lost in the Cocoa jungle. It may sounds a little bit too easy at the beginning ("what is a variable", OK thanks...), but later they explain the Cocoa Classes, and how to get info about them.

Shamyl Zakariya — Jun 05, 07 4224

If only I lived on the west coast. There's hardly any Mac programmers in Washington DC... the ones I've met in Coffee shops are generally using Macs to do Java.

Nehemiah — Jun 05, 07 4227

same here. Andy Matuschak, I'm from St. Louis how did you do it?

Bob Peterson — Jun 05, 07 4228

All good advice, I'm sure. Indeed, I've been programming on a wide variety of machines in a wide variety of programming languages with a w-v of library APIs for over 35 years. Cocoa has been among the hardest. I lack a mental model, an "ah ha" moment of intimate understanding that when I push there and pull here, I know what to expect. I suspect several weeks of immersion (following some of all the advice above) will do the trick. Yet, I have rarely needed such immersion. Cocoa has a very different model than everything else I've done.

As much as I hate M----s--t, my employer required me to write a desktop app in C# and .NET. The closest experience I could bring to bear was Java. That model was close enough, because combined with the MS IDE, excellent debugger, and the fairly fleshed-out .NET help, I was cooking quite fast. Faster than I was with Cocoa. I -still- feel I need to hit Big Nerd Ranch with a few weeks afterwards away from work and distractions.

I look forward to improvements in Leopard, but I'm not holding my breath for parity with .NET even then.

Chinmoy — Jun 06, 07 4232

Great advice Scott. In fact, doing things similar to steps 1-3 in your post has helped me "get" Cocoa.

I also recommend Scott's tutorials and Aaron Hillegass's book, Cocoa Programming for Mac OS X 2nd edition. The book might not cover the latest and greatest topics, but it is great at helping the reader understand the Cocoa paradigm so that he/she can understand Apple docs and other online reference material.

Jeff LaMarche — Jun 07, 07 4237

Good article! I always describe Cocoa's learning curve to new programmers or to experienced programmers coming to Cocoa from other languages as a "grokking curve". Cocoa has a different view of the world than .NET or Java. If you come to the table with some programming background, you can learn the syntax and messaging model and enough to get started programming in just a day or two, but you don't really form a gestalt until you've been working with it for a while. Then, it's like a little light bulb goes off over your head, and you become a raving Cocoa fan-boy. :)

Hmmm... I miss Cocoa... I need to find an excuse (and time) to get back into doing some Cocoa programming.

Blain — Jun 08, 07 4252

> I lack a mental model, an "ah ha" moment of intimate understanding that when I push there and pull here, I know what to expect.

Whereas I "get" Obj-C more than C++/C# mostly because of the stark delineation. Like the McDLT, it keeps the OO side OO and the procedural side procedural. [This posting](http://waffle.wootest.net/2007/03/30/sharp-and-objective/ "Sharp and Objective") might help in a compare/constrast way, as well as things written by [Kevin Hoffman](http://dotnetaddict.dotnetdevelopersjournal.com/ "Dot Net Addict").

Blain — Jun 08, 07 4253

Darn UBB tags. The links again: This posting might help in a compare/constrast way, as well as things written by Kevin Hoffman.

Daniel — Jun 09, 07 4262

Can anyone point me towards an article or guide to best practice-use of error handling in Cocoa projects? I love Cocoa, but the tutorials and books I've read provide little information on the subject. So my Objective-C++ project is a mis-mash of C++ exceptions, Obj-C exceptions, method-returns and asserts. How should one handle errors in Init methods? How should C++ exceptions be integrated into the Objective-C layer? Coming from a C++ background, the static-type protection in ObjC seems surprisingly weak.

Blain — Jun 10, 07 4293

the static-type protection in ObjC seems surprisingly weak.

Yeah. The type-checking on ObjC is one level above (void *), in some ways, which has some advantages (Delegates and dynamic KVC are big wins). In truth, the class doesn't matter as much as functionality. If you check respondsToSelector:, does it really matter if it's a subclass, as long as it handles the right methods?

I love Cocoa, but the tutorials and books I've read provide little information on the subject.

I don't know about Obj-C 2.0, but it really does feel as defacto instead of any organization:

returns BOOL for success or failure

(NSError **) is passed so that an error can be returned.

NSException is another one, mostly for cancelling out of an event.

@try @throw @catch @finally - I haven't used these language-level things as much, and it doesn't look like Appkit uses them.

From the looks of things, methods returning a BOOL and being passed in an (NSError **) seems to be the way to go for minor things, and NSException for failed assertions and the like.

(As I was writing, I found this.)

As for init failures, I'd guess raise an exception, and return a nil for self.

Comments Feed