From: skytag <la...@sk...> - 2007-07-17 00:37:52
|
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. |