Cocoa vs. Carbon

*sigh* They don't need to "cover" for making carbon apps. There's nothing wrong with carob apps. There's this myth that's gone around that cocoa is superior than carbon. But it all depends. One is functional and the other procedural, so some people code better in one type of mindset. It's easier to screw up a carbon app than a cocoa app, but u can still mess up a cocoa app good. Both are native apis, both are first class citizens, both will be around forawhile. Both launch quickly, both provide functionality, both are Good. I personally don't use RB because I only code for OS X and I don't like making 5 mb files that do very simply things, but there isn't anything wrong with using carbon.

F-bacher
 
I would also say there is nothing wrong with Carbon. I produced a UI and code to handle it that runs decently on both MacOS 9 and X, and even though the Interface Builder package chews up 48K, my entire app is seen as 76K by MacOS 9 (old-style OS 9 Package) and compresses down to 8K. Of course it is only the code required to do minimal UI response at this point, but hey, still pretty nice.

Carbon is actually a nice interface for the procedural-minded. However, it includes some nifty things they should have had in OS 8 or earlier, that revolutionize how one handles their application flow, making it much nicer to work with. Unless my app is actively accessing the network bandwidth or doing updating to on-screen gadgets, it uses 0.0% of the CPU as reported by top in the terminal. It is pretty hard to beat that type of proper optimization.

The big issues with Carbon arise from programmers still using the out-dated WaitNextEvent() polling methods, and from just bad programming or flow design. REALBasic is just too bloated a tool IMO, and it makes me glad I got weaned off BASIC when I was still in 5th/6th grade. The C-based languages are currently the best out there for speed/ability combinations. Obj-C included. Carbon and Cocoa just have slightly different feature sets, and different ways you go about things, nothing more.

I can't help it if Apple can't port the Finder over to OS X using Carbon properly, or if RB can't produce good optimized code. I can help it if my Carbon app works good on both platforms, and does what I designed it to do without crashing.
 
I have more problems with Cocoa apps than with Carbon apps.

Cocoa apps tend to assume file paths are constant, and I hate the windows-ish behavior of Cocoa text views.
 
I like Cocoa over carbon. They are just usually more well polished, as many carbon developers don't bother to add things like new icons, mousewheel support, live scrolling etc that i've come to expect from an osx app.
 
You have to also realize that the majority of Carbon apps are just ports from Classic MacOS (90%+). Cocoa apps MUST be written from scratch, and so add that onto the fairly nice API which allows for rather speedy development, and of course you will see the difference.

For example, I am starting a new project in Carbon, but since I don't have the MacOS Classic baggage along with me, I am writing it for OS X, and then making sure it works properly under OS 9 as well.
 
Oh, I know one reason why Carbon apps can sometimes be a little better than Cocoa from an end-user POV.

Cocoa breaks the UI guidelines Apple tried to enforce with Appearance Manager back in MacOS 8. The idea being, if everyone used Appearance Manager-friendly controls/etc, then if Apple changed the look, no harm would come to the app or the end user.

I installed a MacOS X theme today (DSX), which is a nice dark colored theme. However, there is a glitch that only occurs in Cocoa apps: The title bar text remains black. All my Carbon apps start using the Theme's recommended white text, but Cocoa apps seem to ignore this and write it in black anyways. Of course that begs the question, is the fact that Carbon is more hack-friendly a bonus?
 
That's why themes are unsupported, only Carbon apps use the Appearance Manager, Cocoa apps just use some of the theme data but ignore others like the 'layo' resource.

Personally I consider this a minor issue compared to the usability issues.
 
Cocoa apps only started ignoring this data when Apple decided to not allow theming. Plus it is bad programming to ignore this information when it already exists. If they decide to go to a dark theme somewhere down the line (Hi-Tech-ish), they then have to write new code for Cocoa instead of just tweaking the theme data.
 
Hey Strobe,

I've seen you post in a few different places your dislike for Cocoa because of file paths. I ran across this in a Cocoa program I was writing and solved it by

reading
read the data using a path
create an alias (using Carbon APIs)
close the file

writing
open the alias
write the new data

Pretty simple...

I agree, thought, that Apple should not force the programmer to use what is essentially a hack for a broken API. But constant file paths don't mean that Cocoa sucks.
 
I wasn't referring to aliases. An alias is an arbitrary description how to find a file and its behavior is filesystem dependent. Thus aliases leading to files on UFS volumes will be different than aliases leading to files on AppleShare or HFS+ volumes.

Sure, if you want to store the location of a file in a persistent manner then an alias is ideal because you can determine when and how it breaks depending what happens to the file. You can have them behave like symlinks for example (break when the path changes).

If however you want to refer to a file at runtime it would be better to use FSRefs since they don't break like symlinks even on UFS and similar volumes. In that case you don't even need to use Carbon, you can use the closed-source version of CoreFoundation which will convert a NSURL to and from an FSRef.

My problem with Cocoa is it's littered with methods accepting NSString arguments as file primitives and there is no dicipline or guideline whatsoever in how these are to be used. The programmer will assume that he can use POSIX APIs for file I/O without any human interface reprocussions, this is incorrect. I don't know if Apple even plans to address this situation, so far they have only changed the behavior of NSDocument in a manner which suggests it uses an FSRef internally to refer to the file.
 
You must log in or register to reply here.
Back
Top