Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
More than one Mac developer has told me that once I "get" Cocoa, I will wonder why I ever wanted to write code in any other framework. It's a joy to develop in, they say. It's elegant and well-designed. Just keep working at it, they say, and eventually I'll fall in love too.
Well, with all due respect to these fine developers, and having invested many, many months of effort trying to get traction with Cocoa, I must disagree. I don't like Cocoa.
Cocoa offers essentially one avenue to develop GUI's. You can really only build a GUI using Interface Builder: while it's technically possible to specify a user interface in code, it's not well-supported or well-documented. This is in contrast to nearly every other toolkit out there, where GUI builders are available but not essential. For me, this is a hindrance to my productivity rather than a help. I'm accustomed to specifying my GUI in code, by hand; this is how I'm most comfortable. The fact that Interface Builder takes so much code out of the equation (not only the layout of the widgets but the connections between those widgets and the actions they perform) is what I dislike about it. This is not an idle complaint, either. According to Ronald Oussoren, a prominent Cocoa and Python developer, "There is a risk for creating greatly obfuscated programs, because important parts of your program aren't actually in code."
Learning Cocoa is also requiring me to completely reinvent the way I develop. In the process of learning Cocoa, I'm having to learn two separate languages, C and Objective C; as I've written before, this is proving a slow process. In addition to the overhead of learning two new languages, I'm also having to learn the process of developing with a compiled language, rather than a scripting language. It's a lot slower, because you have to re-compile each time you make a change. It's also a lot more complex, because you have to manage memory yourself. Mastering Cocoa would afford me a powerful toolkit--more powerful in some ways than Tcl/Tk and Python, my preferred technologies--but I would lose a great deal of speed and productivity in the process.
It is true that Cocoa can be accessed from some scripting languages. For instance, Python has a well-developed Cocoa binding called PyObjC. (Ronald Oussoren, whom I quoted previously, is the current maintainer of PyObjC.) However, while it avoids the difficulty of using Objective-C directly, PyObjC still requires heavy use of Interface Builder. Worse, PyObjC is currently in a heavy state of flux; it has undergone major updates in the past year, but most of its documentation and tutorials are outdated. The best current approach to learning PyObjC seems to be to learn Cocoa via Objective-C, then translate that knowledge into Python. This means getting on the C/Objective-C treadmill before you can even get to Python. This strikes me as, at the very least, inefficient.
The worst part of learning Cocoa is how much time it's taking me to reach a level remotely comparable to where I currently stand with Tcl/Tk and Python/Tk. It really is a form of shaving yaks. Mucking around with Cocoa is one reason I've gone seven months between releases for PortAuthority and Phynchronicity. I'm still at a beginner level with Cocoa; by contrast, I'm a fairly advanced developer with Tcl/Tk and improving rapidly with Python/Tk. If I'm going to port my applications to a different technology, I want it to be at most a lateral move in complexity. This is how I added Python as a development language to my toolbox; learning Python, and deploying an application in it, took me a couple of months of steady effort. It didn't take months of work just to get to the starting line.
Whatever virtues Cocoa has from a user standpoint do not offset the major obstacles that it presents me from a developer standpoint. Learning Cocoa is proving to be a tremendous, tiresome drain on my productivity as a developer, and I am no longer willing to slow my pace of application development on it.