Hearse and Buggy, Part II
So what are we supposed to do? MIT computer scientist Martin Rinard talks about the idea of the "acceptability envelope," which is based on the realization that for many programs, there's not just a single correct way to execute, but perhaps a range of acceptable responses. This might not necessarily mean different numerical responses (although for many applications it might), but could simply refer to the number of possible orderings of a series of actions. In short, our goal as software creators shouldn't be to guarantee one single trajectory through a large function space, but to define the constraints within which a program is still considered to be correct.
There are many other interesting proposals for making software more reliable, most of which have been around for years, if not decades. Of course, simpler code would be more likely to succeed. Here's a quote, courtesy of my father:
It occurs to me one more time reading that that computer science training, perhaps unlike any other field, is in a complete vacuum from the words of the founding masters. I'll do a longer writeup on that later.
Back to bug-awareness. The hardware reliability folks have an array of techniques, most based on kinds of redundancy and failover. Design-by-contract, assertions, preconditions, and postconditions are ways to constrain behavior, as are, in a small way, languages that support exception throwing (which are finally becoming mainstream).
However, one potential way to deal with bugs is to do the same thing I know you do with Spider Solitaire: Undo. But that would require us to change the way we think about time in software, another one of the bricks of the Turing Prison. I'll talk about that in a couple of days.
So what are we supposed to do? MIT computer scientist Martin Rinard talks about the idea of the "acceptability envelope," which is based on the realization that for many programs, there's not just a single correct way to execute, but perhaps a range of acceptable responses. This might not necessarily mean different numerical responses (although for many applications it might), but could simply refer to the number of possible orderings of a series of actions. In short, our goal as software creators shouldn't be to guarantee one single trajectory through a large function space, but to define the constraints within which a program is still considered to be correct.
There are many other interesting proposals for making software more reliable, most of which have been around for years, if not decades. Of course, simpler code would be more likely to succeed. Here's a quote, courtesy of my father:
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."
-- C.A.R. Hoare
It occurs to me one more time reading that that computer science training, perhaps unlike any other field, is in a complete vacuum from the words of the founding masters. I'll do a longer writeup on that later.
Back to bug-awareness. The hardware reliability folks have an array of techniques, most based on kinds of redundancy and failover. Design-by-contract, assertions, preconditions, and postconditions are ways to constrain behavior, as are, in a small way, languages that support exception throwing (which are finally becoming mainstream).
However, one potential way to deal with bugs is to do the same thing I know you do with Spider Solitaire: Undo. But that would require us to change the way we think about time in software, another one of the bricks of the Turing Prison. I'll talk about that in a couple of days.
<< Home