“Knowing the real goals can make all the difference”

Now, not all applications (or, more precisely, important operations of an application) are amenable to parallelization. True, some problems, such as compilation, are almost ideally parallelizable. But others aren’t; the usual counterexample here is that just because it takes one woman nine months to produce a baby doesn’t imply that nine women could produce one baby in one month. You’ve probably come across that analogy before. But did you notice the problem with leaving the analogy at that? Here’s the trick question to ask the next person who uses it on you: Can you conclude from this that the Human Baby Problem is inherently not amenable to parallelization? Usually people relating this analogy err in quickly concluding that it demonstrates an inherently nonparallel problem, but that’s actually not necessarily correct at all. It is indeed an inherently nonparallel problem if the goal is to produce one child. It is actually an ideally parallelizable problem if the goal is to produce many children! Knowing the real goals can make all the difference.

Optimise for common case

If you’ve ever been invited to an event or group on Facebook by a friend who has lost their phone, and is asking everyone to post their phone numbers so they can recreate their address book, you’ll be pleased to see that Facebook is now prompting these people to do something less stupid.

Don’t know what’s actually triggering this — presumably it doesn’t show up every time someone tries to make an event. Or maybe the problem really is that prevalent, and so it does.

Debugging ain’t what it used to be

Richard Feynman, talking about speeding up calculations during the Manhattan Project:

A rather clever fellow by the name of Stanley Frankle realized that it could be done on IBM machines. The IBM company had machines for business purposes, adding machines that are called tabulators for listings sums and a multiplier, just a machine, a big box, you put cards in it and it would take two numbers from a card and multiple it and print it on a card. And then there were collators and sorters and so on. So he decided, he’d figured out a nice program. If we got enough of these machines in a room, we would take the cards and put them through a cycle…

We had done things like this on adding machines. Usually you go one step across yourself, doing everything. But this was different—where you go first to the adder, then we go to the multiplier, then you go to the adder, and so on. So he designed this thing and ordered a machine from the IBM company… but it was delayed, always delayed… we worked out all the numerical steps we were supposed to do, that the machines were supposed to do, multiply this, and then do this, and subtract that. And then we worked out the program, but we didn’t have any machine to test it on. So what we did, I arranged, was a room with girls in it, each one had a Marchant [a desktop mechanical calculator]. But she was the multiplier and she was the adder, and this one cubed, and so we had cards, index cards, and all she did was cube this number and send it to the next one. She was imitating the multiplier, the next one was imitating the adder; we went through our cycle, and we got all the bugs out. Well, we did it that way.

Taken from his talk, “Los Alamos from Below”, as reproduced in the book The Pleasure of Finding Things Out.

“They blew it”

Q: How do you close applications when multitasking?
A: (Scott Forstall) You don’t have to. The user just uses things and doesn’t ever have to worry about it.
A: (Steve Jobs) It’s like we said on the iPad, if you see a stylus, they blew it. In multitasking, if you see a task manager… they blew it. Users shouldn’t ever have to think about it.

from the Q & A session after the recent iPhone OS 4 event, as reported by Engadget

So what’s this, then?