[Big Mac]

John Nack on Adobe: Photoshop, Lightroom, and Adobe's 64-bit roadmap

This news should not come as a shock to anyone who previously heard about Apple's decision not to create a 64-bit version of Carbon.

[MacosNerd]

Of course so now instead of updating their carbon modules, Adobe needs to port PS to the Cocoa framework. A much more intensive operation. You cannot blame adobe on this one, since apple promised 64bit carbon at WWDC and then changed their minds

[Big Mac]

True dat. But I imagine we'll never see a Cocoa Photoshop.

[peeb]

Originally Posted by MacosNerd 

Of course so now instead of updating their carbon modules, Adobe needs to port PS to the Cocoa framework.

now? You mean, like, a decade ago, right? They've know that carbon was a short term fix for the best part of ten years.

[voodoo]

Screw Adobe. Even Quark has been ported to Cocoa with QXP7 and it wasn't even strictly necessary for QXP, they just realized that there was no future in Carbon and since they're here to support the Mac for years to come, the only logical thing is to port the flagship to Cocoa.

Adobe chose not to, for whatever reasons. To screw Mac users? To pragmatically save money in case they'd abort their support for the Mac?

The end result is just that Adobe is shown to have as lousy judgement of the Mac market as always and that they won't be able to sell us 64-bit PS CS4, but they'll still sell us PS.

[MacosNerd]

never mind

[Big Mac]

I found this comment interesting. Any developers care to respond to these claims? This guy seems to be credible and apparently speaks from experience, but what he's saying flies in the face of what [I think I] know of Cocoa development and the quality of Cocoa apps.

Originally Posted by Nathan Duran

Nathan Duran — 10:49 AM on April 03, 2008

This is one of the very few areas where I simply cannot fault Adobe management in any way. To the general public, and to younger Mac developers who jumped on board after the iPod, it may seem as though they've been dragging their feet all this time, but the reality is that Apple has hasn't expressed much interest in supporting the efforts of third-party developers since the NeXT buyout, and Adobe engineers had every reason to reject the grossly inferior tools they were being offered every step of the way.

First they killed CFM in favor of Mach-O; not because it made any sense at the time, but because Avie stood to profit from Mach-O's adoption. Remember how CFM had all that multi-ISA support in there? Wouldn't that have come in handy during the Intel transition? I personally thing it might have, but I'm not in a position to look at Rosetta's code and offer anything resembling an educated opinion--just uneducated speculation.

Then they gave Mike Ferris free reign over the amount of turd polish that would be applied to ProjectBuilder before it was slyly passed off as a "Mac product." Mike Ferris doesn't like IDEs, doesn't like writing new code, and he really doesn't like comparisons to CodeWarrior. As a result of his refusal to respond to feature requests (even internal ones) with anything other than anger and inaction, ProjectBuilder/XCode is still quite poorly suited for managing large projects spanning thousands of files; it barely handles subprojects, and its buggy-as-hell text editor can't even keep up with my typing speed on a 2GHz machine--something CodeWarrior was able to do effortlessly on a 100MHz Performa more than 10 years ago. XCode's support for shell scripts is used as an excuse for never adding any new features under any circumstances, and Adobe had every reason to resist its adoption as long as they did. During my brief employment at Apple I found that the majority of its own engineers did the same, opting to wrestle with traditional makefiles over dealing with that flaming heap of failure. I mean, this is Apple. Where are the ridiculously experienced UI engineers spending all of their golden time? Certainly nowhere near the 1988 time warp that's engulfed the developer's tools team. Sure, 1.0 was rushed, but 3.1 doesn't look much different once you scratch the veneer.

Adobe would have been flat out nuts to waste time porting Photoshop to Cocoa in 2000. At the time it was little more than a collection of wrapper classes that sat on top of Carbon, and while you could certainly write a fully-featured QuickTime movie player in 5 lines of code, doing anything useful invariably involved finding ways to sneak around behind Cocoa's back in order to get some real work done. Things have improved considerably over the years, and Cocoa is great for small apps that do small things, but it's not a coincidence that Apple's more complicated flagship products never adopted the framework. Cocoa makes life very difficult for anyone who needs to update UI elements outside the main thread or do anything fancy with event handling for example.

Maybe the 64-bit issue will end up forcing Cocoa to achieve the level of maturity it should have struggled for over the past 8 years, but I have my doubts, and my fond memories of PowerPlant's unbridled source access. PowerPlant wasn't perfect, but the fact that it wasn't enshrouded in an utterly pointless veil of secrecy meant that you could fix bugs yourself rather than file a Radar report no one will ever read. If you couldn't figure out why something was happening, all you had to do was hit "Step Into" from the debugger and there was the answer. No disassembling, no DTS incidents; it was right there and you knew exactly what to subclass and overload to work around it. Hell, I spent about two days mangling PP into something that would load (and work!) at INIT time, letting me throw up all manner of fully managed windows and dialog boxes during the boot process. It now takes me longer than that to figure out what stupid thing NSTableView is doing to spin the cursor today.

And then there's the non-standard installer issue that Adobe always gets criticized over, usually by people who don't realize that Apple's PackageMaker is completely undocumented and unusable. It has so many bugs in it that you can easily spend an entire day trying to figure out how to coax it into putting a particular file in a particular location reliably. Try building one or two exceptionally complicated installers for several hundred components, and it becomes immediately obvious that your time would be better spent writing your own installer from scratch--kind of like what Adobe did.

Adobe might be too diplomatic to point any fingers publicly, but their engineers would have to be crazy not to do so in private. Yes, it IS their job to adapt and deliver, but Apple is actively making the situation much more difficult than it should be by hanging on to so many marginally competent NeXT expats who refuse to do the same. My hat's off to anyone who can deal with all of the crap that comes out of Cupertino and still put out a usable product of this size, 64-bit or not. Bypassing ColorSync at printing time alone is a genuine accomplishment these days.

[peeb]

Big Mac, I have no idea about that post - it could be true, but if so, why is only Adobe having issues with this? Surely there are other large, complex apps that should be running into the same problems if this is the case?

[Wiskedjak]

Adobe vs. Apple ... clash of the egos

[MacosNerd]

I've said this before and I'll say it again. I think it makes a lot of sense if apple bought out adobe. Alas, I know that the chances of that happening is slim to none and slim left town.

[Veltliner]

Originally Posted by Big Mac 

True dat. But I imagine we'll never see a Cocoa Photoshop.

Why?

[FireWire]

I liked that comment from MacNN's front page:

Originally Posted by phillymjs

isn't that the excuse...

...they gave us when CS3 was so long in coming?

I would have expected a different lame excuse this time, like the dog ate their only copy of it, or their grandmother died or something.

Seriously, everyone knew from the start that Carbon was only a transition. Adobe has simply no excuses...

[turtle777]

Originally Posted by Big Mac 

I found this comment interesting. Any developers care to respond to these claims? This guy seems to be credible and apparently speaks from experience, but what he's saying flies in the face of what [I think I] know of Cocoa development and the quality of Cocoa apps.

Ok, so first off, I have no effing clue about Cocoa vs. Carbon.

But if Cocoa is the only platform supported in the future, and (at some point deprecated) Carbon is the only platform able to support bigger, complicated apps, doesn't that mean Mac software development is TOAST ?

-t

[Wiskedjak]

Originally Posted by turtle777 

Ok, so first off, I have no effing clue about Cocoa vs. Carbon.

But if Cocoa is the only platform supported in the future, and (at some point deprecated) Carbon is the only platform able to support bigger, complicated apps, doesn't that mean Mac software development is TOAST ?

-t

My guess it means Apple has something up it's sleeve and will be releasing a Cocoa based 64bit graphics editing suite in the near future and is just trying to trim down the competition a bit first.

[turtle777]

Ok, had to do some reading on this.

John Siracusa saw this "issue" for Adobe coming:

Mac OS X 10.5 Leopard: the Ars Technica review: Page 6

-t

[angelmb]

Originally Posted by voodoo 

Screw Adobe.

I also dislike Adobe. They are like the MS for your right brain side… this is not ignorance speaking, I find myself doing the core shapes in Freehand with one tool, I can't even think about that with Illustrator where I have to switch between three, four tools to get the same work done. Not an issue?, maybe if your work is an oval and a square… but place there hundreds of paths and what in Freehand takes one second to achieve is four seconds with Illustrator, do the maths and you will find your working scenario bloated by four times… damn funny.

IF ONLY Adobe improved the core drawing tools this could get better but of course NOT, you don't sell CS3, CS4, CS74 with 'same old but improved tools' banners, you have to place there a new freaking astonishing set of tools anyone running a yet-old CS version could dream to use ever… do they make things easier?, faster?, are they a joy to use?, who really (inside Adobe that is) cares, they are there to sell you on the NEW CS iteration and that's all what matters. You have realized a long time ago unbloated software is a thing of the past. Thank God I still can use XPress and still can use FreeHand, no matter what Adobe says albeit I guess FreeHand days are sadly numbered… so Adobe take note: improve existing features damnit !!

Back on topic…
32bit-whatever but is CS4 going to be intel only?
Hint to Adobe: develope PS for the iPhone

[CharlesS]

Originally Posted by peeb 

now? You mean, like, a decade ago, right? They've know that carbon was a short term fix for the best part of ten years.

Since when? When Carbon was announced, it was supposed to be "the basis for all life." Hence the name "Carbon." Cocoa was originally intended to be "an alternative to Carbon." The way I understood it at the time was that Cocoa was eventually going to be rewritten to be a framework sitting on top of Carbon, so that both would be using the same UI elements and the noticeable differences between them would diminish. Apple didn't just port the OS 9 toolbox over - they added a bunch of new paradigms such as Carbon Events, and in the early years seemed to be improving Carbon much more rapidly than Cocoa, adding new C APIs like the CF* classes that exposed more functionality than the Cocoa equivalents, making you use C for a bunch of stuff that used to be Objective-C in OpenStep, etc., to the extent that I remember a lot of hand-wringing on the cocoa-dev mailing list by ex-NeXT people that were worried that at some point Apple was going to deprecate and/or drop Cocoa, comparing it to previous highly-hyped developer technologies such as QuickDraw GX and OpenDoc that later got axed (here's such a thread from 2002). People were even making t-shirts, mugs, and other such stuff with the [objc retain] slogan on them. And indeed, didn't Objective-C almost get dropped in favor of Java somewhere between Rhapsody and the early OS X developer releases, until people complained to high heaven about it?

This deprecating of Carbon smacks of a new development to me, and one whose motivations are probably political rather than technical. Indeed, the decision came sometime in the middle of Leopard's development - originally there was going to be a 64-bit version of Carbon, it and then it got removed somewhere between WWDC 2006 and WWDC 2007. And if you look in the headers right now, you'll find that a lot of the Carbon APIs are still there in 64-bit, and you can call them just fine from Cocoa apps - it's just the stuff to make your app a full-fledged Carbon app that's missing. Also, if you look at Leopard, you can see that a lot of work has obviously gone into Carbon on it - the noticeable differences between Carbon and Cocoa apps has diminished quite a bit. Also, important applications such as the Finder, the Dock, and iTunes continue to be written in Carbon. Clearly if Carbon was supposed to be a temporary, transitional thing the whole time, no one told the engineers at Apple.

Frankly, I think this is a bad idea. There's nothing wrong with having a low-level API and a high-level one. The two don't do the same thing, and they don't serve the same purpose. Cocoa is great for a lot of apps, but going with a lower-level API like Carbon makes a lot more sense for some types of apps, like games, where performance is essential. Carbon is also a lot easier to develop cross-platform apps with, which is why most of the big apps like Photoshop, MS Office, and iTunes that need to run on both Mac OS X and Windows tend to use Carbon. The other thing is that it's obnoxious how often Apple keeps making its developers retool their apps. The experience is sort of like this:

Apple: OS X is coming out, you're going to have to rewrite your apps.

Developer: Phew, that was a lot of hard work, but we've got the thing working on OS X now.

- later... -

Apple: Surprise! We're switching to Intel. Now you're going to have to rewrite your apps again.

Developer: Dammit, not again!

- still later... -

Disheveled, sleep-deprived developer: <pant> <wheeze> Okay, that's finally done. Now we are finally past all the transition crap and can finally just concentrate on adding features and fixing bugs.

Apple: Yeah, and don't worry, the Carbon framework is going to be 64-bit, so it will be easy for you to bring your app to 64-bit when it needs to be.

Developer: Oh, thank God!

Apple: PSYCH! You're actually going to have to do the largest rewrite you've ever had to do thus far!

Developer: WTF? That does it, I'm either going to cancel the Mac version or it can just sit in 32-bit land forever.

Here's an interesting article on this.

Daring Fireball: The $64,000 Question

[Veltliner]

Originally Posted by Wiskedjak 

My guess it means Apple has something up it's sleeve and will be releasing a Cocoa based 64bit graphics editing suite in the near future and is just trying to trim down the competition a bit first.

Interesting comment.

[voodoo]

Originally Posted by CharlesS 

Since when? When Carbon was announced, it was supposed to be "the basis for all life." Hence the name "Carbon." Cocoa was originally intended to be "an alternative to Carbon." The way I understood it at the time was that Cocoa was eventually going to be rewritten to be a framework sitting on top of Carbon, so that both would be using the same UI elements and the noticeable differences between them would diminish.

They way you understood it may or may not have been wrong, but over a year ago it was clear your understanding was not to be.

Apple was working on 64-bit Carbon, but decided to drop it completely.

As for the name 'carbon' it was indeed 'the base element of all life-forms' meaning it was the common element between Mac OS 9 and Mac OS X. Still reading too much into the name would be a mistake, it's just marketing by Steve and you should know better than to latch on to one of his definitions of truth and facts.