Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

Adobe developer speaks about Carbon 64-bit

Alexandre pointed out that John Nack at Adobe posted about how and when Adobe plans to move Photoshop to 64-bit. This gets much more interesting if you know that Photoshop is a Carbon application, and thus Adobe will have to rewrite much of the Mac-specific parts of it in Cocoa to go 64 bit on the Mac.

John Gruber posts about the $64,000 question and summarizes my thoughts and feelings about the matter pretty accurately. Neither of us agrees with common wisdom that Adobe 'should have seen this coming'. Apple was sending out mixed signals all the time up to WWDC 2007, and even shipped 64-bit Carbon betas.

If you have a large code-base in Carbon that works fine and is already debugged, why would you decide to trade it for a rewrite in a new language, introducing all sorts of new bugs, but ending up with the exact same application you had before?

Reader Comments: (RSS Feed)
JulesLt writes:
Well, one argument would be that you should, theoretically, end up with a smaller and more manageable modern code-base, which would reduce costs going forward. And for a product on the scale of CS, the cost per customer would be low, even though it would be a huge endeavour. However, as John Gruber's post also notes, Adobe's CS apps use their own cross-platform application framework already, so this isn't the case of just porting an application (as it will be with Final Cut) to Cocoa, but bending Cocoa to behave as per Adobe's framework. The cross-platform side also holds them back from being able to use technology like CoreImage to cut their development costs.
Uli Kusterer replies:
JulesLt, the issue with what you call a "smaller and more manageable codebase" is that they already have the code, it works, it's been bullet-proofed. They need to write it for the other platform anyway. All they'd get from using Apple-specific tech would be inconsistencies between the two platforms, and the inability to fix bugs in the code, because most of it sits opaquely in Apple's framework. If it's their own code, Adobe can choose to hire someone to fix it right now. If it's in Apple's code, they have to wait until someone at Apple gets around to it. A DTS incident may speed that up, but it's still on Apple's schedule. I agree that it would be easier to just not be cross-platform, but then it's always easier to drop features than to get them right.
Comment on this article:
Name:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

 
Created: 2008-04-03 @855 Last change: 2014-10-25 @768 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.