Although its a bit tongue-in-cheek, it really shows why Apple investors pay so much attention to Jobs' health. Apple is a very centralized and secretive organization with the appearance that all important decisions, from strategic to design decisions, going through Jobs. No wonder people wonder if Apple can keep being great if he leaves.
Date Founded (1998 vs 1976) is listed as a difference, but really, it's more of a similarity. The "new" Apple, with Steve Jobs at the helm, was founded at about the same time as Google.
I don't know what experience the author of this matrix has in programming, but Infinite Loop's API's have a noticeably higher degree of engineering than any other API / toolchain I've used.
The QuickTime API in C is horrific. It requires tons of unsafe-looking casts and even memcpy()-like operations between types. QuickTime Kit (an Objective C API) was released with QuickTime 7, which can only be better.
Here are excerpts from some code I wrote back in the day to import audio files into Audacity using QuickTime:
// GetMediaSampleDescription takes a SampleDescriptionHandle, but apparently
// if the media is a sound (which presumably we know it is) then it will treat
// it as a SoundDescriptionHandle (which in addition to the format of single
// samples, also tells you sample rate, number of channels, etc.)
// Pretty messed up interface, if you ask me.
SoundDescriptionHandle soundDescription = (SoundDescriptionHandle)NewHandle(0);
GetMediaSampleDescription(mMedia, 1, (SampleDescriptionHandle)soundDescription);
// If this is a compressed format, it may have out-of-stream compression
// parameters that need to be passed to the sound converter. We retrieve
// these in the form of an audio atom. To do this, however we have to
// get the data by way of a handle, then copy it manually from the handle to
// the atom. These interfaces get worse all the time!
Handle decompressionParamsHandle = NewHandle(0);
AudioFormatAtomPtr decompressionParamsAtom = NULL;
err = GetSoundDescriptionExtension(soundDescription, &decompressionParamsHandle,
siDecompressionParams);
if(err == noErr)
{
// this stream has decompression parameters. copy from the handle to the atom.
int paramsSize = GetHandleSize(decompressionParamsHandle);
HLock(decompressionParamsHandle);
decompressionParamsAtom = (AudioFormatAtomPtr)NewPtr(paramsSize);
BlockMoveData(*decompressionParamsHandle, decompressionParamsAtom, paramsSize);
HUnlock(decompressionParamsHandle);
}
This is just dishonest. QTKit was released 5 years ago and works just fine. If you want to cherry pick code from 6 years ago that was originally targeted at an architecture from 15 years ago you can do a lot worse than QT API.
Your characterization of my comment is unfair and untrue. I didn't "cherry pick" anything; the above code is from my only significant experience with any Apple-designed API. The grandparent comment in glowing and general terms praised Apple APIs as noticeably better than other APIs, and this ran strongly contrary to my own experience with them. I even mentioned that this was old code, that QTKit has been released in the meantime, and that it is probably better.
I'm not sure why you think that old APIs designed for old architectures are obviously bad or are not relevant to the discussion. How is C substantially different than in 1994, that newer APIs would be better? Why do you think that architectures from 15 years ago required bad APIs? I can think of many excellent APIs that I was using ten years ago or more.
Feel free to say that the new Apple APIs are much better than the old ones, but my experience says that historically Apple has had some very poor ones.
The Quicktime C APIs have been written nearly 20 years ago for a different OS. The primary goals back then have been performance and economy, not abstraction and clarity.
At the very least, this demonstrates both respect and sympathy for other engineers who need to use an API. Often, it also correlates to a well engineered product underneath.
"At the very least, this demonstrates both respect and sympathy for other engineers who need to use an API. "
Sympathy? As when an API is sort of hacky or kludgey or ad hoc?
"Often, it also correlates to a well engineered product underneath."
When I did Windows development I marveled at the amount and quality of detailed docs available for the platform. In some cases the underlying each was well-engineered, But there's no real correlation. The docs existed because a company really wanted people to develop for their platform.
Docs (or lack of) say more about business than engineering.
Although Google uses data-driven decisions to optimize existing products like the search UI, it's a misconception that strategic decisions of new products and services would be done in a same way.
Of course not. They are made in a similar way that every other human organization does it: based on the intuition and knowledge of the decision makers.
With so many markets they commonly target, and with such a great success one of them has in each market, I cant help but wonder what the implications of a merger would be. Search & hardware, design & algos, high-end & low-end, who could compete with them if they join forces?
Apple has great design skills, but they're still in the desktop era. There's still no compelling online version of iWork, iTunes has been eaten by Spotify in mindshare in Europe, the iPhone still requires syncing. I don't think Google wants or needs any of those pre-internet products.
True, but for how much longer? Already the Cocoa Touch platform supports application installs via WiFi and can use MobileMe for syncing info via "the cloud" instead of a hosting computer. The only bit left is the media library... (and you can buy the smaller stuff like songs and music videos via the phone/iPod even then.)
> Apple has great design skills, but they're still in the desktop era.
As a Mac user for two decades now, it seems to me that Apple is in the process of leaving us behind. The current OS X desktop UI is made more for Windows switchers, and Apple's may-or-may-not exist tablet is expected to continue distancing itself from the desktop flavor of the OS. (I've been doing experimental development for Cocoa Touch over the last couple of months, and I can tell you that despite the "same" language and API, the programming and security enviroments are completely different from the historical desktop experience.)
