The Serving of the Snark

I’ve enjoyed all the recent tweets from the Mac intelligentsia as they try out various phrases with Siri on an iPhone 4S, and report back the often whimsical results. “Open the pod bay doors” is of course a classic, as well as “Beam me up” and “What’s the meaning of life”.

I think the sheer variety we’re seeing, and the, let’s call it the level of teasing, is directly based on how all the content comes from Apple’s servers, not the local copy of iOS on your phone. And that’s for three reasons.

1. Space. As we’ve seen, there are often multiple responses for each phrase. And there are different responses if you’ve repeated a phrase versus saying it new. While each response might only take up a tiny amount of space, 5-10 answers for every single thing Apple engineers think of responding to probably adds up.

2. Schedule. I would bet real money that at least some of the answers that have so tickled the Mac/iPhone tech folks were invented after iOS 5 went golden master, after all the exhaustive testing that was done to ensure that it worked well enough to ship. There just wouldn’t have been time to both finish the feature and add this level of polish for a 1.0 release.

3. Response time. This one’s the killer. I think the reason Apple can provide the cutesy answers that it does is in part because they know they can yank any particular answer in a heartbeat. Otherwise, if they came up with a snarky response that offended someone, that made the news and gave them lots of bad press, the earliest they’d be able to fix it on the device itself might be months away, given other iOS priorities and testing requirements. Apple has a large and busy contingent of lawyers, and I think they would have limited the OS itself to a much more conservative set of responses if they knew they might be stuck with them for a long, long time.

Instead, the Apple engineers must be feeling an unfamiliar sense of freedom. They can provide jokes to statements like “I need to hide a body” and “Talk dirty to me” and “Who’s your daddy”. I’m sure, at some point, we’ll find one that’s in bad enough taste that it’ll make the news.

But we won’t find it for long.

Note #1: I’ve thought a lot about Matt Gemmell’s “SEO for Non-Dicks” article, but I can’t bring myself to switch from whimsical titles to titles “that are relevant to the content”. It’s always going to be a pun or a reference or something. If it keeps me from getting hits, well, I can live with that. Good advice if you’re smarter than me, though.

Note #2: Since I’m talking about snark anyway, I’m going to throw in a plug for Dan Benjamin for his role as co-host on many of the 5 by 5 podcasts. Mostly he’s there to listen and goose things along a bit, but I find that his understated, deadpan snark makes the episodes a lot more enjoyable. The reaction of his co-hosts to the little digs he makes is classic. John Gruber plays along with even drier wit, while both Marco Arment and John Siracusa just kind of pause in annoyance before continuing. It amuses me, anyway.


1. “Bottom Feeding”

Many of my colleagues in the Mac/iPhone/iPad developer community had a deep, personal connection to Steve Jobs, which they expressed on Twitter and in blogs immediately after his death. I’ve never seen anything like it, and I’m grateful for it.

Along the way, I saw a number of attacks on those who didn’t stick to the positive: Daniel Jalkut called it “bottom feeding”, and Jeff LaMarche called it “cruel”, “hurtful”, and “little”.

Personally? The unwavering praise combined with a circling of the wagons made me uncomfortable, and awoke my contrarian nature.

Do you think the man who started phone calls with strangers by swearing at them would begrudge a realistic portrayal of himself after death? Articles on public figures, including obituaries, don’t omit flaws and failures. The page-long article from the October 8th issue of The Economist called “The Magician”, for example, has, amid the tribute, a single-sentence caveat in it.

We haven’t had our caveat yet.

2. “Mourning a Billionaire”

Here’s a tweet from Jana Olsen on October 6th: “Kind of weird how we all went from talking about a huge protest against big business to mourning a billionaire.”

The Occupy Wall Street movement started its encampment in New York City on September 17, over two weeks before Steve Jobs died. His death prompted criticism of the group from both the right and the left. The right made fun of the protesters for the contradiction of protesting the actions of the richest 1% while grieving the death of a very rich one. The left hectored the protestors for feeling any sympathy for Jobs at all.

I’m a lifelong Mac developer. I’m also as liberal as they come, and it’s becoming harder and harder to reconcile the two. On the one hand: the Apple vision of ever-sleeker, ever more useful devices connected to a burgeoning global network of information. On the other: the end of the Western way of life when the oil dries up with no realistic substitute. On the one hand: a thriving consumer market and developer ecosystem providing a good standard of living for many of my colleagues and friends. On the other: deepening unemployment and inequality, fostered by a corrupt media and political class.

3. “Steve Jobs Didn’t”

The always insightful Horace Dediu wrote a clever article using the deflation of some of the myths attributed to Steve Jobs to point out his true accomplishments.

I’m going to be less original, and point out the things that he really didn’t do:

1. He didn’t challenge the entrenched, monopolistic power of most of the industries Apple got involved with. While the big music labels are dying, that’s not Apple’s doing, and in some ways Apple helped prop them up temporarily by dragging them into the digital age. Apple has done nothing to disrupt the movie/television/cable industry that’s in the process of killing TiVo and Netflix. And the telephone carriers, while they can’t dictate phone models like they used to, still follow anti-consumer practices with impunity.

2. He didn’t break the glass ceiling or the tech industry boy’s club. The current Apple executive bios page contains no women. The parts of Apple that I saw had the same lopsided ratios of men to women in their engineering sections as the rest of the industry. I’m not without blame: when I was a hiring manager at Apple, I didn’t try hard enough to find qualified women candidates, and I’m sorry for that.

3. He didn’t help prepare the industry for the post-peak oil era. Bit more of a futuristic point than the others, and even more crazy-hard, but still true.

4. Perhaps most importantly in the near term, he didn’t challenge two great harmful industrial trends, the outsourcing that has all but destroyed America’s manufacturing base and jobs, and the employment of foreign companies that cut corners and endanger workers in order to keep prices low.

You can argue that none of these things were his responsibility, that he had his own company to run and his own vision to follow (which he did extremely well). You can argue that these problems are simply insurmountable or just the Way Things Are—many do.

The reason I think it’s worthwhile to bring these things up in the context of Steve Jobs, in the context of our Mac community, at this very moment, is that our praise of Steve Jobs brings it all to a head: if he was so innovative and unorthodox and uncompromising, if he could achieve the impossible (if he was, as the Onion snarked, the “last American who knew the fuck what he was doing“), what does that say about how we view these problems when we give him a pass on them? They’re worse than impossible? They’re not anyone’s responsibility?

Or as a beginning, maybe this, trite as it is: there’s a lot of bad shit coming down the pike, and we can’t rely on our heroes to save us from it.

Cocoa Swap

A fair number of my colleagues at Apple wouldn’t touch C++ with a ten-foot pole1. Which is a shame, because it has some good ideas.

One idea that’s stuck with me in the 8 years (8 years!) since I wrote my first draft of this post is std::swap().

You use std::swap() like so: instead of doing all your work on your actual objects, you do it on temporary objects instead. Reading in a file’s contents, making a change to your document, parsing a user’s input, it all happens detached from your data model. When the work, and all the possibilities for errors, have been slogged through, you use std::swap() to exchange the temporary objects’ content with that of the real objects.

This is important in C++ because codeflow-interrupting exceptions are a much larger part of error-handling, and because std::swap() is guaranteed not to throw.

Why should I care about this in Objective-C? After all, Apple’s developer documentation goes out of its way to discourage any use of exceptions for normal error handling, instead recommending that methods use NSError parameters2.

Let’s leave aside that it can be rather cumbersome to add an extra parameter to all of your methods, and to be sure deeply nested errors are passed all the way up. Even if no exceptions are thrown, if you encounter an error in the midst of complex changes to your data model, it can be tough to back all the changes out safely. Using temporaries reduces that risk to zero.

Is it worth it? You may, after all, wind up swapping out your entire data model if the changes you’re accumulating are extensive. If you’re working on a 4 GB image file, for example, then this technique probably isn’t for you.

And what if one of the things you’re changing is a file? Here, too, you can swap a temporary with the real thing in a way that’s virtually guaranteed never to cause problems—at least, if you’re willing to drop down a bit from the high-level Cocoa APIs and use Core Service’s FSExchangeObjects() method. (And are willing to bet that a method that uses FSRef types isn’t going to be deprecated. Hey, they ported it to iOS.) My understanding is that FSExchangeObjects() makes only HFS+ metadata changes, if the two files are on the same HFS+ partition. No worries about running out of disk space, permissions, etc. You can use it for ten files in a row, and they should all Just Work.

1. A fair number of my other colleagues at Apple were C++ fiends. ↩︎
2. “Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications.” ↩︎