Sorry this has taken so long to get posted.


Kristoffer Lawson wrote:
>  
>  
>  On 25 Jun 2007, at 10:02, skytag wrote:
>  
> > Kristoffer Lawson wrote:
> >>
> >>
> >> In fact, it has been a public secret for years that Carbon will be
> >> deprecated at some point and that developers should use Cocoa.
> >>
> >
> > Think about what you're saying. A "public secret?" Is that a cute  
> > way of saying that Apple's official position was one thing while it was  
> > actually doing something else? Isn't that also called "lying" and  
> > "misleading their
> > developers?" A lot of people will say "You should have known this was
> > coming," but that's basically saying "You should have known Apple  
> > was lying to you."
>  
>  No, that isn't what I'm saying. Lying is when you say one thing but  
>  mean something else, or basically, when you don't say the truth.
>  
Apple has been saying for years that Carbon would continue to be supported.
Apple never once said prior to the 64-bit announcement that Carbon would
ever be deprecated or crippled (as it is in this case). They did say in the
past year or two that new features would have to be accessed via Cocoa, but
you can do that from a Carbon application. You, on the other hand suggest
that the eventual deprecation of Carbon was always in the plan. I won't
argue that, but Apple never publicly announced that plan. Their official
plan was something different. Too many people are trying to make excuses for
Apple's dishonesty because they could see this coming. The fact that you
could tell someone was lying all along doesn't mean they weren't lying.

Steve stood on stage and said Carbon was a "first class citizen," and at
WWDC 2006 -- just one year ago -- promised 64-bit support for Carbon. 64-bit
support for HIToolbox is essentially complete and could be ready to release
by the time Leopard is released, but engineering management decided to pull
it anyway. How is that not saying one thing and doing another?

It's possible that no one actually lied about this, and that it was simply a
matter of people within Apple not realizing they would do this, but that
kind of flies in the face of the idea that everyone knew this was coming.
Even in this scenario Apple consciously decided to renege on what they had
been telling developers for a year, which isn't what you do if you treat
your partners with respect and integrity.



>  Ever since OS X was released I have heard how Cocoa was the preferred API
>  
"Preferred" does not mean the other alternative is going away.


>  and Carbon was there for compatibility with older applications.
>  
True, but again, it wasn't positioned as a limited-lifetime trasitional
technology. It was used by people with code bases predating Mac OS X and
Cocoa, as well as cross-platform developers.



 Apple has never stated the opposite. 'Compatibility with older ...' sounds
exactly like the kind of API you don't expect to be continuously developed
forever.
>  
This may not be a common attitude, but given the importance of these issues
to developers whose livelihoods depend on them, developers deserve to hear
the straight scoop from Apple. The idea that developers should be expected
to use their crystal balls, Ouija boards, or gut intuition to determine what
Apple's future plans really are is just absurd to me.

Apple should respect its developers and their needs enough to be honest with
them, and in a timely manner. For example, after Apple announced at WWDC
2006 that Carbon would get 64-bit support, a number of developers with
Carbon applications that would benefit from 64-bit support started working
to make their applications 64-bit clean. Some of them have spent many months
on this process. The decision to pull 64-bit support from HIToolbox had been
made by April 2007, but wasn't announced until WWDC in June. I think keeping
that change secret showed a complete lack of respect for the people to whom
Apple had promised 64-bit support the year before. It's not like it's a new
technology being introduced in Leopard.




> >> It's a lot of work to maintain to APIs and does not make much  
> >> sense for Apple.
>  

> > This is true. However, it's no more work today than it was two, three, or
> > six years ago and maybe less. The only thing that's changed is that now
> > Apple feels Carbon develpers have outlived their usefulness.

>  
>  Are you sure? New features or even upcoming features (or platforms) might
>  mean it is increasingly difficult to support both APIs.
>  
I have seen no indication of that. Apple has made changes over the years
that improve support for using Cocoa from within Carbon applications. It's
easier now that it's ever been. In fact, Apple's current position now is
that if you have a Carbon application you should gradually transition to
Cocoa by using Cocoa for new windows and any that need revamping. Before
that they were saying newer features were going to be introduced in Cocoa
and that Carbon applications could access them via Cocoa. That freed them
from a lot of their duplication efforts.




>  
Besides, it's still double the work.

>  
Not Really.



 Corporations aren't charities. If they can do the same thing with half the
work, that's the path they will prefer to take.
- You know, if you applied this same logic to other companies there would be
very few cross-platform applications available for the Mac. Do you think
Microsoft gets the same return on investment from its Mac products as it
does from its Windows products? Supporting Carbon wouldn't be charitable, it
would be doing what they said they'd do. Granted, supporting Carbon wouldn't
result in the same return as supporting Cocoa, but that doesn't make Carbon
a charity. 

- It isn't "half the work." First, there are only four or five engineers on
the Carbon team, out of well over a thousand company-wide. Hardly an
albatross around Apple's neck. Second, a little-known fact is that there are
parts of Cocoa that rely on parts of Carbon. For example, it makes use of
the Carbon Event Manager and the Carbon Menu Manager, which in turn uses
Carbon compositing windows and HIViews. The Carbon Menu Manager will be
implemented in 64-bit starting in Leopard, but only Cocoa applications will
have access to the 64-bit version. The fact is that 64-bit Carbon is already
implemented and now one or more engineers is going to have to do extra work
to remove it. So much for saving work. At the very least Apple should have
provided the 64-bit support they promised, but told developers that no new
features would be added.

- Sometimes it costs money to do the right thing -- such as following
through on your promises. If integrity never cost anything it wouldn't be in
such short supply in people and companies.



>  Just like I suspect that some day a version  
>  of OS X will come out which will not support the PPC machines.
>  
This isn't really analogous. Apple hasn't sold a PowerPC Mac for a while
now, whereas there are Carbon applications still actively developed. In
fact, some of Apple's best-known applications are Carbon applications:
Finder, iTunes, Final Cut Pro, and perhaps others.



>  Additionally, having two APIs also makes it more confusing for  
>  developers, especially new ones.
This is not a reason to drop Carbon. Any disadvantage attributed to
confusion is more that compensated for by allowing developers to pick the
API that's best for them. I've heard more than one developer say his company
will kill their Mac version before they'll rewrite their Mac code to use
Cocoa. Choices are good.

-- 
View this message in context: http://www.nabble.com/No-64-bit-Carbon-%3D-Problem-for-Tk-Aqua
--tf3935997.html#a11293035
Sent from the tcl-mac mailing list archive at Nabble.com.