Fatal Error

As a programmer, this news terrifies me: software glitches in medical linear accelerators caused the deaths of two cancer patients in New York. Unstable software controlling potentially deadly machines is an intensely hazardous mix. These accidents should be of grave concern to the entire software industry—we can be coldly unconcerned when we hear that a buffer overflow attack caused the leak of millions of passwords, but a death is always a more persuasive motivation for improved safety.

In one of the cases mentioned in the Times article, a series of computer crashes apparently failed to save the treatment files for a patient. Between software crashes, the machine operators did not realize that the instructions for the machine were not saved, leaving an aperture wide open for the full dose of radiation.

Unfortunately, this sort of accident is nothing new. Radiation therapy machines have killed people before—the Therac-25 comes to mind—and it’s frightening that the industry has still not come up with stricter safety and security requirements.

The truth is that writing software is hard. I certainly don’t envy the programmers writing software for any system where lives are on the line, but the inevitability of software bugs is a feeble excuse for faulty software. Even though arithmetic overflows and race conditions are notoriously hard to spot, we have tools to minimize them. Static analysis can identify many potential errors before the code is even run. Code written in functional languages can be proved mathematically to be correct.

Accountability, however, is the bottom line. A structural engineer who signs off on a building that collapses after construction will have a difficult time repairing his damaged reputation. If programmers faced similar consequences when lives hung in the balance, there’d be more encouragement to write safe and stable software.

The System Is Down

Can the people file a class-action suit against the senate? Our representatives are more concerned with knifing the other party than the country’s well-being. And the minority party is using an unconstitutional tactic to get their way. That fifteen percent of the population can effectively block legislation backed by the majority of Americans is simply not democracy.

To be clear, I’m disgusted with both parties. Politics will always involve compromise, but the health care debate is bordering on farcical. The current situation has overtones of an exasperated parent calming a tantrum-throwing two-year-old. The Rebublicans have their collective fingers in their ears, stubbornly screaming “NO” while the Democrats keep making concessions in an effort to get the howling brat to stop making a scene in public. Neither strategy is politically viable in the long term.

It’s a shame the current political environment is so hostile to reason that intelligent people with sensible solutions to real problems take the only logical course of action—to stay out of politics.

Cupertino Kremlinology

In preparation to try my hand at Apple prognostication, the standard disclaimers apply: I have no inside information, I am engaging in idle speculation, and I am fully prepared to eat my words. Okay. Let’s get started.

I’m not interested in what unreleased hardware will look like, since it’s safe to say anything designed by Apple will be simple and breathtakingly beautiful (as usual), and will solve the associated design challenges with kick-you-in-the-pants obviousness.* The interesting question I keep coming back to is whether a tablet device will run the iPhone OS, and by extension, run iPhone apps.

First of all, since the rumored tablet would presumably have more in common with an iPhone than your mom’s MacBook—multitouch screen, accelerometer—it’s safe to say it would not be running Mac OS X. Apple has already created a mobile version of OS X—the iPhone OS. Furthermore, it’s clear that Apple has designed Cocoa Touch from the beginning to have enough headroom to grow into a device with a larger screen. (Which might explain why the SDK took so long.) Evidence of this includes the UIWindow class, which exists even though iPhone applications display only one window. I bet Cocoa Touch on the tablet will allow multi-windowed applications.

I would also wager that the device would be able to run existing iPhone apps without any trouble. I’m almost positive, however, that they won’t run full screen. App developers have spent too much time optimizing their UIs so widgets are relatively finger-sized. The interfaces simply won’t scale without usability problems.

Given that size is less of a constraint in a tablet device, I expect the hardware to be powerful enough to support multitasking. This, combined with the presumption that the tablet would run iPhone apps at their native size presents an interesting UI possibility. I envision a dashboard-like layer where a limited number iPhone apps run as widgets on the tablet.

Picture this: iPhone apps launch on a translucent layer where a pair of widgets run side-by-side on the screen. A simple swipe will switch between pages of running apps that don’t fit on the first screen—just like having multiple pages open in Mobile Safari. Capping the number of simultaneously running apps is as simple as limiting the number of pages in the widget layer.

Apple would be crazy to launch a device without the momentum of the App Store behind it, and the only way hit the ground running would be to let existing iPhone apps run on a tablet. In the end though, Apple has spent far more time thinking about these problems and refining the solutions than all of the armchair product-designers and rumormongers combined. I may be wildly off predicting the app switcher, but it’s a fairly safe bet that whatever we see next Wednesday will blow us away.

* I won’t speculate on text input other than saying that I don’t expect to see Inkwell, Mac OS X’s pen input software, anywhere near this thing. Considering there’s no page dedicated to Inkwell on Apple’s website, it’s easy to guess how Jobs feels about this technology.

The Future

First of all, I’d like to get one thing out of the way so we can move on. The title of the post has to be read (either silently, to yourself, or—preferably—out loud) in a voice like the narrator of this video. Thank you.

Alright, where was I? Oh yes.

We live in an age where my operating system can auto-detect my printer and auto-install its drivers. But a corollary of Newton’s third law states, for every advance in usability there is always an equal and opposite set of new and baffling features.

Take “high altitude correction,” for example. I had no idea that printers could suffer from hypobaropathy. Hey Samsung engineers, can’t you just throw a barometer in there and auto-tune that setting yourself?

Whatever. It was kind of cool that I could auto-enjoy my dinner last night instead of spending two hours manually downloading and installing printer drivers.

Neurotic

I am cleaning my apartment right now even though I should be programming but actually have five different drafts of Tumblr posts open in five different windows which is marginally nettling to my compulsive aversion to clutter that somehow inevitably is overcome by entropy as my desktop degrades into full-on dishevelment regardless.

Time is the factor here. More specifically that there isn’t any, but that doesn’t cut the number of things I need or want to do in a particular day. I have code to debug, projects to manage, specifications to write, and I’m supposed to blow away a baker’s dozen of readers with literary brilliance here? It takes too long for the words to congeal. Dammit, a literary soufflé takes time.

But my spare time is finite and while it would be nice to learn Haskell and maybe tell you about it I would need to teach myself monads first and I just don’t have time for that and besides it kind of sounds dirty. Instead I have unread novels essays treatises critiques interviews theses monographs in stacks that collect pages and dust and value. It is precisely this moment that I start to wonder what kind of programmer I am given my preference for reading Foucault, Eco, Venturi, Perec, Jacobs, Bringhurst, or the late-great-DFW over staring at a screenful of parentheses semicolons and square brackets. I mean come on why would anyone prefer to savor the elegant compositions of artists who meticulously craft their prose?

Mix That Metaphor!

“In early February, that’s when the rubber hits the road or the shit hits the fan,” Ratnieks concluded.

— “Bee Colony Collapse May Have Several Causes” Wired Science, 8 January 2010.

Unhelpful

Clearly the xml_set_object function takes two arguments: the first is a parser, a featureless gray rectangle, and the second is an object, a similarly featureless gray rectangle.

It’s almost unsportsmanlike to make fun of an easy target like PHP. Almost.

You Can’t Take True From False, False Is Less than True

or, PHP’s new math

Sheer brilliance. Unsarcastically, of course, when referring to the title, “Ghost Equals Ghost, but Poison Is False to Steel,” and content of Adam Parrish’s short post on PHP’s type comparison game and Pokémon’s truth table for some bizarre form of fuzzy logic.

The sarcasm is reserved for situations where a few simple rules designed for convenience produce disastrous user experience when applied concurrently. The Double Equals Loose Comparison Matrix appears, at first glance, to be an arbitrary construct of a language designer’s twisted, sadistic brain.

After a bit of archeological excavation, we find that there may be method behind the madness. At the very least a lesser lunacy is involved, since the type conversion rules below describe the mechanisms at work behind the seemingly chaotic scattering of Trues and Falses above.

But we do not get off quite so easily. PHP would not allow it. Why is False less than True? (Boolean values shouldn’t have a numerical order.) If “array is always greater” when comparing an array to any other type, and “object is always greater” when comparing an object to any other type, what happens when you compare an object to an array? These are the uncertainties we face when we concern ourselves with the hermeneutics of PHP.

APL Functional Symbol Tilde Diaeresis

⍨

That is all.

Things Startups Do and Don’t Need

(This is based on a pair of lists by Chris Dixon. I don’t agree with some of what he says, so I’m compiling my own list. This is not an exhaustive checklist, but an exploration of what makes the spaces I’ve worked in productive or not.)

Location is everything, both on a macro (the region—Silicon Valley, New York, or the Research Triangle) and micro (the neighborhood, the daily activity of the city) scale. It’s important to be near other bright, innovative companies. The office should be easily accessible by public transportation. There should be a variety of places to eat (both sit-down and takeout or delivery) nearby. Maybe even a bar to get drinks with coworkers after a long day. Jane Jacobs might be of some help here.

Read More