Originally posted by mdriftmeyer
People need to realize a ton of work went into reinventing the wheel just to keep legacy developers happy FOR OVER SEVEN YEARS.
COCOA is the Future of OS X.
Don't believe me. Go get a job at Apple Engineering.
I don't think you really understand what's been said already.
The line between Carbon and Cocoa is so blurred nowadays, it's pointless to dispute this anymore. A "Cocoa" Fnder would perform no more or less poorly than the current Finder. Rewriting IMHO would njot provide any huge benefit.
If anybody cares to remember, iMovie was a Carbon application. Then with iLife 05 Apple rewrote it as a Cocoa application. It was S-L-O-W as molasses. So much so that they released two successive updates to make performance tweaks. It still feels like it's got molasses stuck to its GUI widgets. The same thing with iPhoto, which was written from scratch as a Cocoa application.
The Finder's problems stem from three problems:
- A poorly designed network filesystem implementation. The spinning wheel of death when using AFP or WebDAV has nothing to do with Cocoa vs. Carbon; that fact can be confirmed by running a dev tool like Sample on the Finder when it starts spinning. Anybody with knowledge of OS X programming could see that the Finder is spinning because the underlying filesystem call like stat() (a BSD call that Cocoa would use as well) is blocking, waiting for the networking operation to complete. Now, they COULD put that operation on a seperate thread, but that brings me to my next point.
- All GUI calls on OS X are un-thread safe. Cocoa and Carbon are both un-threadsafe WRT to their widget API calls. Anybody that's tried to update an NSTableView from inside a thread will tell you that Cocoa is no better than Carbon in this area. So the Finder team cannot just spawn a new thread to update the GUI, because the GUI cannot be updated from inside a thread. And it's impossible to tell if a filesystem API call will block before you call it.
- Blocking APIs are NECESSARY when working with files in order to ensure consistent and non destructive behavior. For example the user might click on a file, causing the finder to call stat() on it so they can determine the permissions of the file (so you know what operations are permitted on the file). If they spawned a thread when you clicked on the file to call stat(), then what happens in the mean time? Should you be allowed to double click the file? You may not have permissions to do so.
The Finder has other problems besides the networking filesystem, but they are mainly problems as far as I can tell with the underlying frameworks of OS X, not with the implementation of the Finder.
It's ludicrious to think that Carbon vs. Cocoa actually makes a difference anymore. Several APIs in Cocoa are built ON TOP OF Carbon, and Carbon makes use of Cocoa calls as well. Cocoa's Menus are drawn with Carbon; events in Cocoa are dispatched using Carbon Events.
Furthermore, what IS Carbon? Is it anything not Objective-C based? Is it APIs that came from OS 9? If so, then the QuickTime, AppleScript, and many other OS X frameworks that Apple tout so heavily would go away if Apple were to get rid of Carbon.
If you are STRICTLY speaking about the widget APIs in Carbon.framework, then you are talking about something that cannot possibly affect performance, etc. on the order of magnitude that most people assume.