Originally Posted by stuffe
I don't think anyone actually cares that it is 32 bit. What they are more likely to me complaining about is that it is still written using the old Carbon development tools that Apple publicly chide other large developers for being slow to move off (Microsoft, Adobe, etc). Pretty much everything else written using Cocoa, which allows access to the APIs etc for all the clever goodness that is available like Grand Central etc and so on to allow apps to be more responsive and efficient, and less likely to give you the spinning beachball. iTunes still beachballs me when it starts to rip from a CD, it wouldn't do that if it was written in Cocoa (or at least has the potential to be written in such a way as to prevent it). It would also compile in 64 bit with Cocoa.
Of course, this is all very technical, but the shorthand is that if it's still in 32 bit, it's the most obvious sign that it's been written using deprecated development techniques. It doesn't need 4Gb RAM, and doesn't need to run in 64 bit, but by doing so it would get all sorts of very useful and welcome side effects, such as not sucking quite so much from a performance perspective.
I'm a huge fan of Cocoa, but the above is completely false. Cocoa apps are not inherently faster. In fact, they're actually slower, although not meaningfully so. Cocoa is higher level and technically has less direct access to functionality.
There are some apps that would be faster if based upon things like grand central, but I don't think iTunes would benefit much at all. Filtering and displaying this amount of tabular data, isn't something that would benefit much from additional multithreading.
The problem (if you are of the opinion that there is one) is not the language and APIs of the iTunes code base, but rather the age of the iTunes code base. Some programs can mature over time, becoming quite optimized and robust. However, iTunes has had tons of functionality added over the last decade, meaning that it was hard for the code to ever reach a clean and stable state. Also, keep in mind that Apple is trying to maintain perfect parity for the windows version. This means that it has to be reliant on lots of crusty portions of quicktime unless they want have two completely separate code bases for Mac and Windows. But again, this isn't a carbon vs cocoa thing.
The iTunes code started out as SoundJam MP after Apple bought the code and hired the developers. The quality of SoundJam back in 2000 was astonishing. It already felt like it was made by apple. It had responsive live window dragging and scrolling even though the Mac OS had yet to pull these things off successfully. Performance was pretty mind-blowing actually.
A complete rewrite could certainly result in a cleaner architecture. But that is just it. It is the cleaner architecture, not the change in language and APIs that would lead to better performance. Carbon is more than capable for what is required in iTunes. With that said, if doing a complete rewrite, cocoa would be the right choice.
Finally, at this point in the migration to cocoa, we should actually be happy that apple is still basing some of its software on carbon. This means that carbon will be better supported for all those apps which may never get completely rewritten from the ground up.
Ah... the nostalgiahttp://en.wikipedia.org/wiki/SoundJam_MP