Re: Carbon vs Cocoa arguments
Re: Carbon vs Cocoa arguments
- Subject: Re: Carbon vs Cocoa arguments
- From: Eugene Lee <email@hidden>
- Date: Thu, 10 Oct 2002 05:51:38 -0500
- Mail-followup-to: email@hidden
On Thu, Oct 10, 2002 at 10:48:07AM +0200, Izidor Jerebic wrote:
:
: On Tuesday, Oct 8, 2002, at 23:48 Europe/Ljubljana, Scott Corliss wrote:
: >
: >This actually goes against what you're trying to prove, but might give
: >you a little different viewpoint on Carbon.
: >
: >
http://www.unsanity.org/archives/000024.php
:
: It naturally depends on what you do, but for developing a normal
: application with GUI, there is simply no way Carbon can be compared to
: Cocoa. It is much easier and faster to develop such an application in
: Cocoa with less bugs. Just compare source examples from Apple for
: somehow similar apps - TextEdit in Cocoa and SimpleText in Carbon. And
: then see the Sketch in Cocoa for example of drawing app. If these
: examples won't convince you, well, there's Apple's recommendation to
: develop new apps in Cocoa, which they adhere to (everything new is
: Cocoa).
These are RAD-type arguments to be made to developers. I'd like to see
more discussion on performance that is more visible to the end user.
The section that I found most interesting was this one:
Cocoa is generally SLOWER than Carbon, despite what most public
thinks. (When a Carbon app wants to call a function in itself,
it jumps directly to the function address; when Cocoa app wants
to do the same, it goes through a single (ok, there are a few
variations of it) function called objc_msgSend which finds the
correct address and jumps to there. This means each time a Cocoa
method calls another Cocoa method there's 16 to 80 instructions
overhead compared to Carbon. A true bottleneck, however it is
not a design flaw but rather a decision that makes objc quite
flexible to make it achieve what it needs to).
So, my point? Cocoa is not better than Carbon; its just
different. Do not assume Cocoa applications are better than
Carbon. This is often true (bug-wise) due to the fact Cocoa
implements lot of high-level sh*t Carbon developers have to much
with themselves, which cuts the number of bugs in UI code
significantly. However, not all Carbon applications are crap.
Look at Finder (lets keep aside the missing functionality
aspects here) - it is a PowerPlant C++ application. Compare it
to SNAX. Which is faster? When it comes down to tables drawing
speed, Finder wins hands down. So don't think Finder would be
all that faster and better if it was Cocoa. It wouldn't.
Some of the feedback has been interesting:
- Cocoa is a very high level API. It provides an awesome amount
of power and consistency for free. Cocoa is also designed to
solve a relatively general purpose set of development
problems. As such, it is not highly optimized to any one
particular development problem. While it is often trivial to
create a powerful application that exhibits most of the
desired features in a relatively short amount of time, it can
be require a lot of effort to make the program work extremely
efficiently.
Posted by: b.bumgarner on October 1, 2002 06:18 PM
As for mixing and matching APIs:
In 10.2 Carbon & Cocoa UIs can be mixed at the window level --
that means that a Carbon app can host a Cocoa window and vice
versa. I haven't tried this myself, but it looks promising and
is a peek at what future plans are.
Post 10.2 Apple will make it possible to mix and match Cocoa &
Carbon at the widget level - Cocoa popup menu & Carbon checkbox
in the same window. That's the marketing spin on it (After all,
Apple has to market to devs =). My theory is that this means
that Cocoa is going to move to complete sit on top of Carbon. Of
course, for this to happen really means that everything that
Cocoa does today will arrive in Carbon, and must.
Posted by: Rincewind on October 2, 2002 07:50 AM
And as for Finder:
As for speed of PowerPlant vs Cocoa. An application is not fast
because of its API, Language, or Framework - it's fast because
of design and implementation details. The Cocoa based Finder
(known as WorkSpace Manager) on NeXTStep 2.0 on 68040 hardware
was faster than the finder in Mac OS X 10.0 on a G4. It was
comparable to the Finder in 10.1. NOW the Finder has finally
gotten up to speed. And it finally has some of the cool
inter-application communication and services that the original
NeXTStep Workspace Manager. IE 5 had dismal performance as a
Carbon app until recently. A lot of this has had to do with lack
of use (or improper use) of Carbon Events. But for Apple's
supposed flagship application, the Finder, to suffer speedwise
like it did until Jaguar, is NOT a ringing endorsement for
Carbon. While again - Workspace Manager ported fine to Mac OS X
Server 1.x (which was essentially NeXTStep 5.x).
Posted by: j.shell on October 2, 2002 10:47 AM
Thoughts from the developer gallery?
--
Eugene Lee
email@hidden
_______________________________________________
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.