Re: Apple and Developers (was lots of different subjects) (rekindling the fire)
Re: Apple and Developers (was lots of different subjects) (rekindling the fire)
- Subject: Re: Apple and Developers (was lots of different subjects) (rekindling the fire)
- From: Jeff LaMarche <email@hidden>
- Date: Sat, 23 Mar 2002 23:21:37 -0800
On Saturday, March 23, 2002, at 10:07 PM, Andrew R. Mitchell wrote:
>
First off, I'm tired of this Carbon vs Cocoa, Objective-C vs C++ flame
>
war that is going on. Both Carbon and Cocoa are key for the future
>
success of Apple. And neither is perfect for everything. API choice
>
along with language choice should be based on the task at hand. Some
>
things Cocoa is better for, some things Carbon is better for. Some
>
things C++ is better for, some things Objective-C is better for, and
>
lets not forget some things an alternate language may be better for
>
(AppleScript, Java, Ada, Smalltalk, Dylan, Perl, Python, etc). Not
>
every language or API is suited for every task.
Out of curiosity, how much time have you spent using each of the tools
you mentioned? My perception could be skewed, but there do not seem to
be many Carbon proponents who have really taken the time to learn Cocoa
well so they can do a fair comparison of the two technologies. It really
seems like most Carbon developers are there by default, because they
wanted to keep doing what they're used to rather than face the learning
curve of a new API.
I've programmed the Mac for about 16 years - 14 years using the Toolbox
API (first in C, then C++) and less than two with Cocoa. I also program
in several other languages and for other platforms (bizarrely enough,
the Mac is one of the few platforms I've never been paid to write code
for). The Mac was the first machine I did any serious programming on and
the Toolbox API using C probably accounts for more of my time coding
than any other API or language. I approached Cocoa warily, but wanted to
learn it well so I could make an informed decision about which API to
use going forward. Here are my feelings on the matter.
I do agree with the basic premise of your statement - that no tool is
right for every job and that having options is good. And you're right
that Carbon is important for the success of Apple - but for practical
reasons, not because of Carbon's appropriateness for any given task.
There are certain tasks that Carbon does better, but only because those
are Apple technologies that weren't supported or didn't have a corollary
in NextStep. Cocoa can take full advantage of those things, however,
whereas Carbon programs cannot really take advantage of Cocoa at all.
I would say that I have a fair understanding of both APIs and of
programming in general, and I firmly believe that there's very little
about Carbon to defend from a technical standpoint. It's a set of
functions and data structures originally developed under one procedural
language then later under another, so it's got a lot of Pascal quirks in
it. It was originally developed for use in a non-multi-tasking kernel
then mutated into a cooperative multitasking environment, and has some
scars from that. Hell, it was originally designed without support for
colors (well, actually there was some very rudimentary color support in
there before the machines even supported it, but that's another story),
and it shows vestiges of that. The Toolbox API evolved chaotically;
there was little guiding methodology and almost no awareness of design
patterns. There is absolutely nothing elegant about it - it was a
long-running hack: a brilliant brute force job of making things work
against all odds. It's impressive in many ways, and especially
impressive that the Toolbox API was made to work both on X and Classic -
two very different operating systems - via Carbon. But the first
Airplane, the Model-T, and many other now-obsolete things were also
impressive in their day.
If you've spent any time reading or studying the science of developing
software, you'd have trouble claiming that Carbon with C or C++ is a
better choice than Carbon for many tasks of any complexity. You could
make a marginally defensible position if you made the use of a fairly
mature framework like PowerPlant a quid pro quo, but even there, Carbon
falls short. Someday, something will supplant OOP, but there's no
obvious replacement on the horizon for developing complex applications
in a maintainable fashion, and Cocoa, despite being old enough to drive,
is still way ahead of the curve as far as providing programmer
efficiency and logical program organization. There are few cases, if
any, where Carbon makes sense in the long run. Putting emotion aside,
even long-time Mac shops with millions of lines of Toolbox code would be
better off switching to Cocoa: Even those areas where Cocoa is
deficient, you'd be better off creating your own objective-C classes to
interface with the CoreFoundation or with Carbon than using that as an
excuse to program solely in Carbon. Remember, all the Toolbox code
you've got can be accessed from Cocoa.
Apple needed Carbon for one primary reason - many programmers want to
keep using what they are used to (hell, I work with Cobol programmers
who have always and only programmed in Cobol), and Apple couldn't afford
to totally alienate their long-time developers (although they don't seem
to mind pissing them off every now and again =) ). Cocoa/Objective-C is
not perfect, but it is (for the most part) an elegant framework
architected by people who had studied and learned from the lessons of
past software development. It is not a panacea and is not the right tool
for every job, but put Carbon and Cocoa head-to-head without
interference from emotion, and it is unlikely that Carbon will even put
any points on the board.
_______________________________________________
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.