Comments on: Apple moving Finder to Cocoa

One of the last Apple-developed applications written in the Carbon programming environment has been rewritten using Apple's Cocoa programming environment, according to a report.

[AidenShaw]

Isn't headlining the article with a publicity image from Apple a little bit over the top? It certainly seems to show more than a little bias in the story.

[sciontcya]

Take it easy Ballmer, you'll get your Windoze 7 shots up soon enough...
Good lord, isn't there enough of this whining on the political blogs?

Pfft.

[seanadb]

Aiden, headlining the article with the image from Apple doesn't show bias so much as laziness. This isn't a pro-Apple article, it's simply information on an update of the OS. (whether the writer has a bias or not isn't an issue since this subject doesn't have much contentious issues in it).

Cheers!

- Sean

[Mr. Dee]

The question is, how much will they be charging loyal OS X upgraders for this release? Lets face it, OS X has been marketed since 10.2 around the idea of features, features. 10.6 features are more maintenance updates than revolutionary or even evolutionary changes. The name itself suggest minor. I just can't see the average Mac user paying $129 for ZFS read/write, theoretical support for 16 TBs of RAM, better Exchange Server and Active Directory integration. This looks more like Apples aim to get new users possibly from the Windows fold which will give Apple some serious footing into the Enterprise.

I have come up with several theories around Snow Leopard. Could it be the release that Apple finally makes available on generic Tier One OEM PCs?

[iertry]

I wouldn't be too surprised of they charged the normal price but I think it will probably be around $99 if it's just the stability they've been talking about. I reckon they will include some cool features though to try and justify charging the usual $129

[timber2005]

You think with their desktops and macbook sales through the roof that they would release for the general pc? What would be the motivation?

[Penguinisto]

@Mr. Dee - probably not... Apple's business model is highly successful because they're the only place to buy a brand new OSX pre-install (the mediation/arbitration w/ Psystar notwithstanding).

It's not in their best interests to turn over OSX to the tender mercies of OEMs who more often than not cut corners and specs just to get a margin.

[sciontcya]

You have NO IDEA what this will cost - do you?
No.
There's a lot going on, and speculating at this point if you don't know anything - and you don't - is just acting the fool.
Sit back and wait.

[wfolta]

In some sense, Apple has been adding features to the OS which haven't fully hit the user space yet. The Core's come to mind, and there are quite a few others, like being MobileMe- and Time-Machine-aware.

In addition, things like ZFS read/write could have a huge impact on what Time Machine 2 offers. And let's not forget the main point of this thread which is a rewritten Finder. Surely you don't think they're simply going to make it look and work pixel-for-pixel like the current Finder, do you?

For developers, Apple's doing something rare: cleaning up the loose ends. And there's a lot of benefit for users when developers are cared-for. Also, I imagine that the Snow Leopard feature set will really help Apple in not only the "Enterprise" market -- where it may be more of a first or second step on a long march -- but it could give it a huge push in recapturing universities and other infrastructures where it's very popular at the user level and so already has leverage in the infrastructure.

[kelmon]

So, when your comment is roughly translated, you don't actually know very much about Snow Leopard, do you? I'd like the update to be free but the chances of that given the fact that the foundations of the OS are being replaced, this seems unlikely. If all you think it is delivering is ZFS and 16GB then you're going to be in for a shock. Can I recommend reading up on it before writing such nonsense? Just a tip...

[coryschulz]

Isn't Leopard already 64-bit? It was my understanding that all of the current iMacs with the Core 2 Duos were already 64-bit and can already support more ram than a 32-bit machine. I'm not sure why I'd ever need more than 4GB of ram anyways, and I do stuff like video editing and audio recording with Pro Tools.

[Tom Krazit]

You can run 64-bit applications on Leopard, but Snow Leopard will be a 64-bit kernel, while Leopard has a 32-bit kernel.

John Siracusa at Ars Technica covered the implications of this pretty well last year: http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6

[kcotham]

Well, applications keep getting bigger and bigger and requiring not only more storage space, but more RAM as well. Remember when Bill Gates said that he didn't see how anyone could ever need more than 640K of RAM? Ten years ago the Mac OS would run very quickly in a machine with far less than 64MB of RAM. Now I'm running Mail, Safari, and iTunes, and Activity Monitor in 1.3GB of RAM! It's called looking forward. The more RAM a machine has, the faster it gets (in most cases).

As for whether or not OS X is 64-bit, I think it runs in 32-bit on Core 2 Duo machines and only runs in 64 bit on the Xeon machines like the Mac Pro. I could be wrong about that though.

[TheNetAvenger]

1) No OS X is not 64bit, it only enables applications to access a 64bit address space for RAM.

2) The Ars Technica article only touches on the subject, and mainly from a development framework standpoint. (Even one of the more technical articles at AppleInsider tries to stick to the Address space of 64bit and jumps over a lot of the technical issues facing Apple, and getting some of them flat out wrong when they reference how easy it will be or how it would compare to Vista x64.)

3) Snow Leopard is 'supposed' to be a full 64bit OS and 64bit kernel, but that is not set in stone, as moving OS X to a full 64bit kernel will require a lot of new drivers and kernel level changes that may be outside of what Apple will want users to go through. (Even Vista, MS had to force everyone to support 64bit drivers to get the Approved logo, or Vista x64 would have been left behind like XP 64 was.


If Snow Leopard does go full 64bit, look for issues and migration problems, like people saw from System 9 to OS X and users also see moving from XP/Vista x32 to Vista x64 - Although MS forcing Vista x64 support for logo requirements has made Vista x64 pretty painless and a good stepping stone so that Windows 7 will by default sell the x64 version more than the 32bit version.

It is kind of ironic that Apple claimed to have the first 'desktop 64bit computer', and to this day, OS X still isn't 64bit.

BTW...

64bit brings more to a computer than just a larger memory address space. There are 64bit registers and other internal optimzations that 'DO' make a difference when running at the kernel level of an OS. Vista x64 has less table tracking because of the 64bit space and also can speed up 32bit applications by shoving two memory read/writes into one and use the full 64bit chunk of RAM the OS allocated. (On average - especially gaming - Vista x64 runs 15-20% faster than Vista x32 if the computer has 1.5 or 2gb of RAM to make up for the extra RAM allocation overhead. - And yes this is even with 32bit applications running on the 64bit OS.)


So for Apple, shoving Snow Leopard to a full 64bit kernel is a gamble, as it could go well for users, like the Vista x64 crowd is seeing with better performance, or it could be a nightmare with driver issues and software migration problems. Apple has more control of the hardware and drivers, so in theory it should be significantly easier than what MS went through with XP 64 and literally forcing software and hardware companies to support Vista x64 if they want the logo or any certification.

Summary: 64bit is better, and Apple could be giving you something really good if they iron out the kernel level driver and other core migration issues needed for a full 64bit OS.

[Perry_Clease]

"I have come up with several theories around Snow Leopard. Could it be the release that Apple finally makes available on generic Tier One OEM PCs?"

Why in the hell would Apple want to do that!

[flithm]

This is actually a big issue, and something I suspect might drive a big wedge between Apple and some its major application developers (like Adobe). What this means is if you want to have a cross platform application (like Photoshop) not only do you need to mix two GUI APIs, but two languages and compilers as well.

Think of the nightmare of having to write a GUI abstraction library that does the same thing in C++ and Win32 API, as well as in Objective-C and Cocoa. Not only that but imagine the task of having to port Photoshop from using Carbon to Cocoa. Not fun.

I think the next release of photoshop will mark a big moment for Apple, where for the first time Photoshop will be better on Windows than on a Mac. And it's all because Apple has decided to deprecate Carbon.

[Vegaman_Dan]

Apple's recent moves have puzzled many people in the graphic and photography fields. The new hardware lineup of Macbooks will have those glossy screens which I admit look great and give you very nice deep blacks for things like videos, but as photography and graphic reviewers are saying, this makes them ideal for all sorts of applications including movies, games, and internet usage. The fact that colors get shifted with the glossy screens and cause glare issues will really only affect applications that require accurate colors- you know, like photography and graphic use.

I think we're seeing Apple move more and more away from their core and more towards consumer electronics.

[Mr. Dee]

Don't bet on this release being a catalyst that makes third party apps popular on Windows better on the Mac and drawing people over. Apple will not catch Windows in market share because they refuse to do things in the Windows way that major Enterprises like. Road maps, predictability and the venerable compatibility. The fact that Photoshop CS4 is 64 bit for Windows and not for Mac, show that progress and opportunities still shine for developers on Windows. Apple holds back just too much which in turn disadvantages the platform. For a Company like Adobe, I would have expected them to work closely, at least tell Adobe from WWDC 2005, Carbon 64 bit support is not a guarantee for 10.5, start investigating the option of moving the codebase to Cocoa. At least Adobe wouldn't be wasting a bunch of time on code that would be thrown away. Maybe CS4 would have been the release that introduced the first full 64 bit release of Photoshop for OS X.

[Critical_Mass]

I have owned Adobe software since 1992.
I just bought Adobe CS3 via upgrade in late August = $606.00USD.
In less than 30 days they sell CS4.
All it will cost me is another $606.00USD.
I called in to Adobe to check = NO MERCY.

At least Apple knows better than to pull a stunt like this.

Adobe: Dance with the one that brung you.

Apple is a much better dance partner.

[TheNetAvenger]

Apple did kind of screw over Adobe and everyone, as they promised full 64bit carbon 'forever', and when Apple hit some tough issues, decided to kill it off completely. (Same with many of their earlier Quarzt GPU acceleration promises that were eventually killed, after some developers had invested a lot of work in slow performing Quartz work, with the promise of it getting faster - instead it has been replace by new APIs a few times, even though they all still have Quartz in their name.)

-MS took hell for pulling support/features from Vista before it was even released, imagine if they did what Apple is doing and canceling promised features of a shipping OS and key OS development frameworks.

On a side note, Adobe doesn't like to play nice either and still tries to strangle the market with over the top pricing and degrading software quality. (Flash's performance is scary bad in recent releases, let alone their Acrobat reader.)

Adobe doing 64bit versions on Windows was a pretty easy decision for them, as the API migration Microsoft designed is barely more than just recompiling for 64bit, no framework changes, no dead end API sets. Even 16bit Win3.1 applications from 1990 can fairly easily be moved all the way to 64bit because of the agnostic nature of the Windows API set. (Vista's new APIs with .NET 3.x will be the 'major' move for developers in the next 5 years, and even it can be mixed and matched with Win32/64 APIs as developers are already doing. Microsoft's own Expression Design is a Win32/64 core with a new Vista WPF interface, which is pretty cool considering the massive difference between the two API frameworks and how easily this is for developers.)

(Sorry got off on a developer ramble.)

[skellener]

Adobe has refused to embrace OS X since it debuted. The only reason we even have Carbon (always considered a temporary stop gap for legacy developers) was to appease the likes of Adobe - a dinosaur of software development. An yes, that is what Adobe does - write software. Or at least they used to. They have ignored the direction Apple has taken for a decade and it is now biting THEM in the ass. I do not feel sorry in the least for Adobe. They have taken our money for a decade of pitiful updates. Well, it's time they actually earned that money. Yes that means rewriting parts of their applications. Isn't that what they are supposed to do as software developers? Write software? Why all the complaints? They just need to do their job.

[ppgreat]

"I think the next release of photoshop will mark a big moment for Apple, where for the first time Photoshop will be better on Windows than on a Mac. And it's all because Apple has decided to deprecate Carbon."

I'm a little doubtful of that. Adobe still has to contend with both Microsoft and Apple coming out with (somewhat) competitive products. Also, who knows what rewrites will be in the works for Windows 7 compatibility?

[tyoungbe]

@flithm Not as much changes besides the View and interaction between the View and the original libraries would really be needed in a change to a Cocoa project. You could write the whole thing in Obj-C, but you can also just write C++ code and reference it in the Obj-C app controller class that you create. UI is still the really big difference, not the underlying engine or the compiler for that matter. You've always had to use a seperate compiler between Mac and PC.

I'm not saying a port would be painless, just that Obj-C is far more flexible for cross platform dev then some people think.

[man_w_balls]

"Isn't headlining the article with a publicity image from Apple a little bit over the top? It certainly seems to show more than a little bias in the story."

No. It's not much different from Jimmy Page raising his Gibson guitar in the air during a rockin' moment. Why didn't he give equal time to Fender or Rickenbacker or [whoever]? He's simply celebrating a choice he prefers, which flamboyantly gay people could understand. Not that Apple is flamboyantly gay, or that being gay is wrong, but...
Jimmy Page totally rocks!! And Apple makes a hell of an OS. The End.

[ckurowic]

Here is some clarification for everyone: http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6

[tonybelding]

OK, this is really puzzling news to me. . . My question is: How did Finder ever get written in Carbon to begin with? I'm assuming the Mac OS X finder wasn't simply ported over from older Mac OS, that wouldn't make much sense (and it never looked or felt like the old Finder either). If they were going to port a desktop from anywhere, it should have come from NeXT. Why would Apple, early in Mac OS X's development, have even considered doing Finder in Carbon? In any event, I hope they take the opportunity to overhaul Finder and make it work more consistently. It's a bit of a mess.

[kelmon]

In all honesty, this has bugged me as well.

[mbenedict]

@tonybelding: Apple introduced Carbon as a "first-class" C++ API alongside Cocoa. The message at the time was developers could write apps in Carbon or Cocoa (or even Java or BSD) and receive full support from Apple.

Apple wrote Finder in Carbon specifically to showcase Carbon. Writing a major system in Carbon also allowed Apple to "shake out the bugs" in Carbon. It was an "eat your own dogfood" exercise.

Today we of course see it differently; Carbon became the API for "ported apps" (both older MacOS apps but also Windows apps) while Cocoa has become the preferred API. But that wasn't the messaging when Carbon first came out.

Apple quickly realized that maintaining four separate "first-class" APIs was a really dumb idea. Lots of wasted duplicate efforts, interoperability problems, etc. For awhile they tried to "fix" this by layering parts of Cocoa on top of Carbon. The positioning became nuanced with Cocoa becoming more of the "GUI-layer" API, while Carbon more the "low-level" C++ API. This half-assed layering just created a bigger mess.

So eventually Carbon became deprecated, Java (as a first-class API) was thrown out in the cold, and the BSD layer was left for whatever can't be done elsewhere (e.g., Cocoa couldn't do 64-bits, so you had to write your 64-bit code in BSD.)

But again initially Carbon was a "first-class" API and hence Apple had no qualms writing Finder in Carbon.

The big problem for Apple in the future is that everyone is moving away from C-based APIs (be it C++ or Objective-C), while Apple is going to be "stuck" with Objective-C MacOS's primary API. We see this with the proliferation of managed, virtual-machine based environments -- especially Java and .NET but also dynamic languages in general.

That's why you see Apple kludging with things like the Python-Cocoa bridge (PyObjC). Microsoft doesn't have this problem because they were able to concentrate on the CLR. You can run managed C++, C#, VB, Python, Ruby, etc., as first-class CLR languages without the need for bridging.

[Penguinisto]

@mbenedict: Not quite. By 2005, it was widely known that Carbon was the bridge library set, and Cocoa was the goal. Carbon is/was still used with multi-platform apps (for good reason), but Cocoa is not hard to port to.

The Python/Cocoa bridge was Apple's efforts to accommodate Python bridging to Cocoa... Microsoft has _no_ such native analog or bridge for Python, Ruby, or Perl - any bridges out there for Windows/VS are written by volunteers and are swaged-in, with little-to-no efforts or help at all from MSFT. Also, remember that MSFT's efforts at J# was more an attempt to destroy Java than to accommodate it (which in turn was an attempt that failed miserably).

You too easily confuse ancillary languages (e.g. Python) with core languages. That trick may work with the typical user types, but you're not fooling anyone in the programming world. You also forget that Apple has easy gcc integration within Xtools - gcc can accommodate pretty much any language in existence.

Funny you should bring up VB - MSFT is desperately trying to kill it, pushing world+dog to .NET instead. 'splain that one, big guy.

Finally, your statement that "everyone is moving away from C-based APIs" is laughable at best, and a subjective opinion that lacks any factual basis.

/P

[mbenedict]

@penguinisto

Your ignorance is stunningly amazing.

1) Apple would not write Finder in Carbon if at that time Carbon was simply a bridging library set. That would just be plain stupid. Or maybe that's what you're saying, Apple is stupid? Besides, by 2005, OSX was already four years old.

2) Python and other languages do not have "bridges" to Microsoft APIs, *because they are not required*. They can run as first-class CLR languages, unlike on MacOS.

3) Python analog for Microsoft written by "volunteers" with no help from MSFT? You should be ashamed by your ignorance. Any pythonista can tell you that of the most popular Python environments -- IronPython -- was written by Microsoft. http://msdn.microsoft.com/en-us/magazine/cc300810.aspx

4) MSFT trying to "kill" VB in a push to .NET?? What idiotic comment is that? VB *is* one of the MAJOR .NET languages. Not only VB.NET 2008 just came out but the upcoming VBx (aka VB10) will be a large feature of Silverlight 2.0.

I know you're an Apple apologist, but really, this is shocking even for you.

[whclevelandjr]

@mbenedict

I'm a little confused by your #2. I think you are confused by the term "bridge". Most other folks would call it a framework. You know like ironPython is a framework for .Net, Jython is a framework for the Java platform, PyGtk is for Gtk, PyKDE is for KDE, ad nauseam. So you are completely wrong about Python not needing a bridge to the Microsoft API, it's called ironPython and you mentioned it in your comment.

As for #4, I've been a windows developer for longer than I care to admit and I can say with conviction that Microsoft always gave me the impression that they would like to phase Visual Basic out in favor of C#. I'm glad that Microsoft has decided to continue to support VB, but I see it as a sign that they underestimated how embedded VB has become within their enterprise market share. I've always questioned Microsoft's logic behind the initial phase out, since some people where moving to Java (and its lack of vendor lock in) instead of sticking with Microsoft and its C#.

You seem happy with working in a Microsoft environment and more power to you. Maybe one day you'll venture out and try better technologies...

[The-Gdog]

It seems this will cause a lot of compatibility issues with software. if thats the case i am NOT upgrading I
will keep leopard!

[Martin Pilkington]

@The-Gdog: It won't cause any compatibility issues, at least no more than happen with any OS X update (ie those developers who do things they shouldn't may find their apps break). Carbon is still supported, it's just not available for 64 bit UI development (it should be noted that most of what initially made up Carbon has been modernised and moved to other APIs or replaced by entirely new APIs. Apple is basically saying that all the old bits left over and the Carbon UI layer shouldn't be used any more).

@mbenedict: "everyone is moving away from C-based APIs"? That's one of the most laughable things I've ever heard. The rest of the paragraph also highlights how little you know about Objective-C and Cocoa. I mean: "We see this with the proliferation of managed, virtual-machine based environments -- especially Java and .NET but also dynamic languages in general. "

The fact that you would consider Java dynamic is ridiculous. Java is incredibly rigid compared to a language like Obj-C. Obj-C is a runtime based language, Java is a compiler based language. There are things you can do in one or two lines of Obj-C code that the Java compiler would complain about and so you have to write new classes in order to work around it leading to many more lines of code which adds complexity to your system.

I suggest picking up a book on Cocoa and learning to code in it. Then you can come back and make some informed statements about Mac development.

[dsjove]

I find this "first -class" language distinction interesting but does not describe the problem. I am also seeing the somewhat ambiguously defined word "dynamic" being thrown around. And "runtime and compiler based language" makes no sense. They all have a runtime and they all have compilers.

The language grammar, the language's runtime environment, the language's libraries, OS libraries available to the language and most importantly what problem is being solved - all need to be considered when discussing this problem.

Java was dumped. Its runtime is heavy. It has poor system integration. And Steve has no control over it. If Apple did a MS like solution, poeple could write to Cocoa (not Java Cross-platform Runtime) using the Java grammar. But the language features of Java is smaller than Obj-C++.

C/C++, despite what Benedict says, are still huge. Strousup is focusing C++ for systems programming. I would never want to write another UI or dynamic system in C++ (given its runtime)! But the language features and upcoming library (Boost) are extremely powerful. I love that I can take advantage of C++ within Obj-C++.

Obj-C++. There is Cocoa. It is by-far the best application framework out there. To really take advantage of it you need the language features of Obj-C. That is one reason why Apple does not want to support the other languages that are not smalltalk-like.

Carbon is a C-based Facade for accessing MacOSX libraries while looking like MacOS9. MS does not abandon old APIs. Apple always has. There is nothing cross-platform (besides chunks of the Quicktime library) about Carbon. If Adobe was smart they already have clean a Mac/Windows/Model separation in their code. Time to update the Mac UI!

So why did Apple rewrite the Finder in Carbon? It could have been political (Please don't abandon us Adobe). It could have been a time saver - huge reusable chunks already written to the Carbon API. It could have been internally political - some manager had a personal investment in Carbon. I doubt it was because Steve wanted it in Carbon. Remember when MacOSX was introduced (and Apple was still in the Doghouse) Steve told everybody that the MacOS9 APIs were going away. He had to switch that position rather quickly. They ain't in the doghouse anymore.

[mbenedict]

@Martin Pilkinton: I did NOT write that Java was a dynamic language. I wrote that **VM based environments** (like .NET and Java), and dynamic languages (like Python and Ruby), are replacing C based APIs. Java in this sense is NOT THE JAVA LANGUAGE but Java as in the JVM. Do you know the difference?

Furthermore, saying that Java (the language) is compiler-based while Objective-C is runtime-based is just plain DUMB and totally misses the point. Maybe you're awkwardly trying to say that Objective-C has dynamic typing instead of Java's static typing, so I'll give you the benefit of the doubt , but that's still misses the point.

The point remains that the rest of the world has moved away from C-based APIs for application development , while Apple is going to be stuck in it.

As far as picking up "a book or two on Cocoa" -- hey get a clue I code (and audit code) on the Mac (and MS and Unix) on a daily basis as part of my job. I've written more Carbon and Cocoa apps than most readers here combined.

[Martin Pilkington]

@mbenedict: I apologise then. However you are drawing boundaries that don't work with Obj-C. You're grouping Obj-C in with C and labelling Cocoa a C based API, implying that Obj-C isn't dynamic. In reality Obj-C is just as dynamic as python and ruby. By runtime-based I mean a language uses an extreme late binding messaging system. Obj-C is dynamic in the sense that you can use dynamic typing if you wish, but you can also do things like check if an object implements a method at runtime (this will throw a compiler error in Java), add new code while the application is running, generate methods on the fly etc.

And while you may have written many Cocoa apps your comments here either show a lack of understanding of Cocoa or a need to over generalise and wrongly classify Cocoa and Obj-C in order to make a flawed point.

[mbenedict]

@Martin:

I understand Cocoa just fine thank you. Static vs. dynamic typing in this case is irrelevant. Objective-C has dynamic typing, but no matter how you slice it, Objective-C is still C-based and suffers because of it.

Some examples:

1. Memory management is largely manual and error prone. Like other Mac programmers I've spent countless hours debugging errors caused by retain / release problems, and often the culprit lies deep inside Apple's own frameworks! If even Apple can't get this right then you can understand the scope of the problem.

Yes Objective C 2.0 adds garbage collection, but this breaks compatibility. Programs using GC even in "backwards compatibility mode" will NOT run on anything but Leopard, which is bizarre and illustrates yet another weakness with a C-based API. If you're writing commercial software today, GC is not an option. If you're writing apps for the iPhone, then GC is not an option either.

2. Buffer overflows, pointer arithmetic issues, etc. All the "C" evils remain in Objective-C. Not just to cause programs to crash, but all the associated security issues as well (allowing arbitrary code execution, etc.)

3. Poor optimization. Objective-C is slooow, in many instances slower than, say, Java. Being a strict-superset of C means most modern optimization techniques can't be used. Want JIT-based runtime branch optimization? Sorry, no can do. Dynamic typing just makes this even worse because the compiler can't do many static optimizations either. Here Objective-C takes on the worse of both static and dynamic worlds.

4. Poor interoperability. The fact that we have Carbon vs. Cocoa at all shows how bad and wasteful C-based APIs are.** You have two largely-incompatible interfaces for two primary C-based OO languages (I'm oversimplifying a bit.) In a managed enviroment like .NET or Java (as in the JVM), you can code in many different languages all sharing the same types and runtime and libraries. Compiled vs interpreted, static vs dynamic binding, early vs late typing, etc., doesn't matter in a VM world.

Lastly, look at the software development world today. On the server-side the battle is .NET vs Java vs dynamic languages (Python, Ruby when not running on top of .NET or Java.) On the web (and spilling into the desktop) it's AJAX vs Adobe AIR vs Silverlight.

NONE of these are Apple technologies. Bad news for Apple. Even on mobile devices the main battle is Flash vs. Java (be it Java-ME or Google's Android platform.) Apple knows this, which is why they don't want neither Flash nor Java on the iPhone... losing proposition for them.

The vast majority of coders I know who have a Mac don't have a clue about Objective-C besides maybe doing a tutorial or two. Instead the vast majority of them are Java programmers -- they fire up Eclipse on their Mac and deploy to Tomcat or Weblogic or whatever on Sun or Linux. They might think Cocoa is "neat" but quickly get frustrated with IB and turned-off by the prospect of going back to a C-based language.

** I'm talking about application development, not systems programming.

[Martin Pilkington]

@mbenedict: I'd say being C based is a huge advantage for Obj-C as you get huge benefits such as access to the vast range of C APIs and the power that C provides (you list some of these as disadvantages but they are incredibly powerful if not used incorrectly). Now, to address your issues:

1. Yes, memory management is manual and being manual it is error prone. But it's not like it is complicated. And if there are any problems with leaks then you just fire up Instruments and it will help you track them down. One of my apps was ballooning up to 300MB of RAM if left open for a day. Spent 30 minutes in Instruments tracking them down and fixing the leaks and now it rarely goes above 25MB.

Yes there are memory leaks in Apple's APIs, but in that case you can just file a bug and they'll fix the leak, bug generally leaks in Apple's APIs are rare due to their widespread use.

And yes, GC can only be used on Leopard, but the same goes for Core Animation, Image Kit, the rest of Obj-C 2.0 etc. Apple doesn't bother porting new technologies back to old versions of OS X because there's no technical nor financial incentive for them to do so. It complicates things for their developers and reduces the reasons for people to upgrade.

2. Yes, those problems still exist, and yes the standard practices for securing them are still valid.

3. You got some benchmarks for that? Obviously Obj-C will be slower than some languages because of the fact that it does a lot more in the runtime. Of course you are sacrificing a bit of performance for a huge gain in flexibility, clarity and brevity of code. I'd rather write less code, cleaner code and not feel like I have one hand tied behind my back than gain the few ms of performance. And if I needed that performance I'd drop down to straight C. And of course if you need to optimise Obj-C then there are plenty ways to do it: http://www.mulle-kybernetik.com/artikel/Optimization/index.html

4. Actually the reason for Carbon and Cocoa existing is because they came from two backgrounds, like Win32 and .Net. And Cocoa isn't bound just to Obj-C. There are bridges for Ruby and Python officially supported with other languages with unofficial bridges. And on top of that there is MacRuby, which is Ruby but built upon the Obj-C runtime (which acts as a VM in a way) so that it uses the Ruby syntax but native Obj-C types with no need for converting over the bridge.

Now, looking at your software development landscape, I agree that it is .NET vs Java vs Dynamic languages on the server and the web is AJAX vs AIR vs Silverlight (vs Flash). And yes Apple doesn't own any of these. I would say though that they have a large stake in them. AJAX for example, is heavily pushed by Apple. Apple doesn't feel the need to build their own system when AJAX is powerful enough. Instead they build the best rendering engine with the fastest Javascript interpreter on the web, which is used in Safari on the Mac and PC, Google Chrome, Android, Nokia Phones and the iPhone and iPod touch.

And on the mobile it has been Flash vs Java. The problem Apple has with these technologies on the iPhone is this:

Flash - Adobe seems to refuse to optimise Flash for OS X. If it runs like crap on the Mac then it won't do well on the iPhone. There's also the issue of multi touch requiring different input formats and unless flash developers are going to re-write their sites/apps for the iPhone then it's going to be a 2nd class experience

Java - Java is poor. It is an awful language with even worse APIs that weren't designed as much as they were just fired out of a shotgun with the hope that something workable would appear out of the mess. To go with APIs that push you away from making good user experiences you have the fact that Java has an absolutely huge pool of developers, being one of the main languages taught in universities and schools. This means it is where all the mediocre developers are.

Now it may sound snobbish but Apple doesn't want mediocre developers on their platform. They want the best developers making the best apps with the best UI frameworks around. If these developers don't like the power given to them by IB and prefer to write code instead, or they're incapable of using a C-based language then Apple doesn't care, as there are better developers out there who will see the huge benefits to IB and are fine working with a C-based language.

[sanjayb]

@Martin

Java - Java is poor. It is an awful language with even worse APIs that weren't designed as much as they were just fired out of a shotgun with the hope that something workable would appear out of the mess. To go with APIs that push you away from making good user experiences you have the fact that Java has an absolutely huge pool of developers, being one of the main languages taught in universities and schools. This means it is where all the mediocre developers are.

You have no clue on what u are about. You obviously haven't programmed in Java. Some of the best programmers I know program in Java. If Java is a poor language why is it so widely used? I would hate to see what API's you would come up with.