Google vs. Apple
businessweek.com
businessweek.com
That one, I'd venture.
Any specific examples?
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.
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.
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);
}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.
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.
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.)