Re: Carbon vs Cocoa arguments
Re: Carbon vs Cocoa arguments
- Subject: Re: Carbon vs Cocoa arguments
- From: Ondra Cada <email@hidden>
- Date: Fri, 11 Oct 2002 13:56:47 +0200
On Friday, October 11, 2002, at 06:44 , Ryan McGann wrote:
Cocoa is generally SLOWER than Carbon,
This is *NOT* true.
As you point out, this depends on the situation.
Yup. And therefore is just is not *generally* true. Am I not understand
plain English or what?
I can certainly write
a Carbon application that is much faster than its Cocoa counterpoint.
Certainly. And I can write an assembler-based one which would be a blue
lightning compared to the one of yours.
The most important point is that the Cocoa app would be finished in a week
(presumed a simple app), whilst its Carbon counterpart -- if you wanted it
to offer comparable services, stability, and also the speed -- would take
at least a month, probably more. Moreover, it would be a bitch to maintain
and upgrade, whilst with the Cocoa app it tends to be comparatively a
child's play.
Of course, the same stands for the assembler one: it would be much more
faster than Carbon, but it would be also much more difficult to make,
maintain, and upgrade.
This is very natural, and if you think of it also quite understandable,
rule: the more hi-level and abstract API you use, the faster and simpler
development, the easier maintenance and upgrades -- and the slower the
result (presumed algorithms are precisely the same).
Even if we stopped at that, it would mean generally Cocoa's better, since
for *VAST* majority of apps the development speed, stability, simple
maintenance and upgrading is just *so much* more important than raw speed.
Nevertheless, there's more to that -- with the time spared you can, as I'
ve already written, use it to polish algorithms and optimize bottlenecks,
which means that in practice a Cocoa app would not only sooner hit market,
be more stable, more featured, easier to maintenance and upgrade, but
*also* faster.
Of course, you can trade: you can eg. use the time saved to overstuff the
thing by features, leaving out any optimization (like it seems to be with
ProjectBuilder).
Normally though the exact opposite is true: the much higher abstraction
level and easy-to-useness of ObjC with Cocoa libraries allows you to
focus
on the problem, which tends to end with a better algorithm. The
inevitable
result is that Cocoa apps tend to be actually *FASTER* than
Carbon-or-whatever-other-API apps, made with roughly comparable effort:
you lose some ticks here and there, but get O(n) instead of O(n*n) for
exchange ;)
This depends on the programmer and the application. A lazy programmer
will take the easy road, which is to use NSNumer's stored in an
NSArray.
Yup. And since...
Very few applications are doing heavy number crunching.
...it would very probably show that his laziness was the most reasonable
thing to do, for the lost of speed would prove completely unimportant (in
order of a tenth of second at a keyclick or so), whilst the difference in
development speed (=price), result stability, maintenance-freeness (=again
price), and upgradability is *VASTLY* important.
If not, well, profiling would show the bottleneck and it would be time to
re-write it using C++ and Carbon API, or more probably plain C and BSD API,
or even -- if the worst comes to the worst -- assembler and
hand-optimized Altivec code.
Again, what is *immensely* important to grasp is that the speed of the
original Cocoa development makes free time for this. OTOH, if you have to
implement Services or spellchecking (and zillion of other things) yourself
lest they don't work, as it is in Carbon, you lose this time futilely in
tasks which could and should work automagically -- and there would be no
remaining one for necessary optimization (if any).
The Finder has many issues with it. I can make a Cocoa applicaiton
however that's just as slow as the Finder, if not slower.
This doesn't seem to be the right way of argument. I surely can make an
AltiVec-assembler-optimized application slower than anything given, just
exploiting a few exponential algorithms. So what?
Much of the
Finder's problems stem from problems that Cocoa has as well: the UI is
_not_ thread safe for the most part. The Finder was sped up in Jaguar
from spawning new threads, which was possible due to improved threading
capabilities in Jaguar
I don't know Finder implementation, but did you appreciate that the UI
does not need to be thread-safe the slightest bit to allow multithreaded
apps? With a half-decent design, there's the one UI thread, and any number
of worker ones. After all, the OpenStep UI was much less thread-safe than
OSX one is; nevertheless, Workspace Manager did much better multithreading
than Finder does now.
Cocoa developers have a slight knee-jerk reaction to Carbon, shying
away from it as much as possible.
That's quite simple: if you got used to an excellent set of power tools,
you naturally shy away from home-made rough half-nonfunctional bend
screwdrivers and hammers with loose heads. The somewhat allergic reaction
is there sice, due to the very sad fact there are some APIs which are *not*
available in Cocoa, we are *forced to* use the measly API quite often,
which of course increases our aversion.
Carbon is still very viable, and has
to be if the Mac will be a major player in the PC market considering no
major commerical applications have been written in Cocoa yet.
This is another can of worms I would rather not open again: it was
discussed to death and over already. The short answer: had Apple not
pollute Mac OS X by the Carbon stuff, there would be -- after all, there
*were* ones even for NeXTStep with its infinitely less userbase ages ago,
from companies like Adobe(!) or Lotus.
The point is, use whatever you want. Cocoa uses Carbon but is easier to
program for. Carbon is backwards compatible for those 80% of the Mac
users still using OS 9. And in the future, they will merge further and
become dependant on the other, making stupid arguments like this moot.
Should we just argue each other, it would be moot all right. Don't forget
though the thread begun by a question of someone who does not know either
Cocoa or Carbon yet, *selecting what to learn*!
That's where this argument comes very very useful. Unless the person needs
OS9-codebase-compatibility, it would be extremely unclever to go the
Carbon route: the difference is just too big. The point is that unless he
tries he can't know -- and from posts like yours it might seem that it's
roughly equivalent to write in Carbon and Cocoa, since the advantages and
disadvantages more or less balance -- and *that* is far from truth. Unless
you explicitly *do need* Carbon for some reason or other, it would be just
*futile* to select it over Cocoa.
In short: the rational Mac OS X development is
(a) if you for some reason need to stick with any specific API (be it
Carbon, BSD, Java Swing...), just use it;
(b) otherwise, always use ObjC/Cocoa as the main API;
(c) with very small parts, preferrably in separate wrappers, for those
things Cocoa does not support (yet).
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.