[Commentary] Cocoa vs. Carbon

Wil Shipley seems to have started what eventually would become a big rolling snowball with his entry linked in my previous entry. It's gotten Daring Fireball and Scott Stevenson talking. What's going on here is a grievance against the fact that several frameworks Cocoa programmers must use are only available in Carbon. Why is this a big grief? Carbon frameworks are written in procedural C style language which is a big departure from the object oriented style of Objective-C. The reason I prefeer Cocoa/Objective-C myself is because it's so easy to use and get straight to what you want. A good starting example of this is CTGradient which I am using for various elements in AssignmentTracker X currently. CTGradient is an Objective-C wrapper around Core Graphics (which is written is Carbon/Procedural C) and because of that I can write a couple lines of code and be done with it. To be specific heres a short example of a NSView subclass using CTGradient copied straight from AssignmentTracker X's 2.0 source code

@implementation ATXStartupWizardBackgroundView - (id)initWithFrame:(NSRect)frame { self = [super initWithFrame:frame]; if (self) { swGradient = [[CTGradient unifiedNormalGradient] retain]; angle = 90; } return self; } - (void)drawRect:(NSRect)rect { [swGradient fillRect:rect angle:angle]; } @end

simple and really easy! All you have to declare in the header is a CTGradient instance and a float for the angle, and if you take a look at the CTGradient source code... well it's doing a lot for you for such a simple function of creating a simple gradient grafted onto a NSView. In fact way more than I'd ever want to begin to show you here, just download it and take a look at it for yourself and you'll get an idea of why if this is a lot for just a gradient, it must be a ton for other functions. It's not that C is crap, far from it. I still continue reading through The C Programming Language 2nd Edition written by Denis Ritche himeself and appreciate a lot of things in C. C is a good programming language but in some instances like it's used in Carbon, it clearly shows it's limits. Heres something that's never really been said yet (at least not directly), when your going from Cocoa to Carbon your literally thrown from one world to another. When your in Cocoa your relatively familiar with the bounds, limits and expected behaviour of cocoa world, then suddenly your thrown into the land of procedural programming. At the very least Apple should be aware this severely limits the learning curve for new programmers or even Cocoa veterans who have never touched Carbon before and thus limits the productivity of the mac developer community as a whole. I have to agree with Wil Shipley here in that regardless of Carbons origins it's only been used as a compatibility library and really to help all the Mac programmers out there we need to move all the frameworks to Cocoa. When they are all moved to Cocoa, Apple can do all the optimizing on the backend and provide us with an easy Objective-C interface on the frontend in a similar way that they did with Core Data, thus reducing the amount of code in all apps, increasing programmer productivity, and allowing more of the devleoper community to show off all the great stuff in Mac OS X.