Clock-free Computing

As an undergrad at MIT in 1972, I took a course in asynchronous design from Prof. Jonathan Allen. Having some background at the time in digital circuitry, it was exciting to see this latest work as presented by Allen, and it was easy to imagine that in a few years most computers and other digital systems would operate this way. The reasoning was much like what Ivan Sutherland advocated in his Viewpoint “The Tyranny of the Clock” (Oct. 2012). Following graduation I started out in the working world designing digital hardware. Industry opens a student’s eyes to the real world, and it was clear rather quickly that the synchronous world would not in fact budge for a long time. Though my work today involves mostly software, I still see the appeal of asynchronous logic and hope the vision of asynchronous computing finally takes hold. We could use more calls-to-arms like Sutherland’s: “The clock-free design paradigm must eventually prevail.” I look forward to that day, just as I look forward to another paradigm that should eventually prevail—parallel processing.

Larry stabile, Cambridge, MA

Relational Model obsolete

I write to support and expand on Erik Meijer’s article “All Your Database Are Belong to Us” (Sept. 2012). Relational databases have been very useful in practice but are increasingly an obstacle to progress due to several limitations:

Inexpressiveness. Relational algebra cannot conveniently express negation or disjunction, much less the general-ization/specialization connective required for ontologies;

Inconsistency non-robustness. Incon-
sistency robustness is information-
system performance in the face of
continually pervasive inconsistencies,
a shift from the once-dominant para-
digms of inconsistency denial and in-
consistency elimination attempting to
sweep inconsistencies under the rug.
In practice, it is impossible to meet the
requirement of the Relational Model
that all information be consistent, but
the Relational Model does not process
inconsistent information correctly. At-
tempting to use transactions to remove
contradictions from, say, relational
medical information is tantamount to
a distributed-denial-of-service attack
due to the locking required to prevent
new inconsistencies even as contradic-
tions are being removed in the pres-
ence of interdependencies;

References

1. Hewitt, C. Health information systems technologies. stanford university Cs Colloquium EE380, june 6, 2012; http://HIst.carlhewitt.info

2. Hewitt, C., Meijer, E., and szyperski, C. The Actor Model. Microsoft Channel 9 Videos; http://channel9. msdn.com/shows/Going+deep/Hewitt-Meijer-and-szyperski-the-actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

Design software for the unknown In his article “Software Needs Seatbelts and Airbags” (Sept. 2012), Emery D. Berger identified typical flaws in coding, as well as techniques that might help prevent them, addressing a major conundrum taking much of a typical programmer’s time: Much more time goes for tracking bugs than for writing useful programs.

Berger’s analogy of software techniques and automobile accessories was illuminating, though computer technology has generally outpaced the automobile by orders of magnitude. Some have said automobiles could go one million miles on a single gallon of fuel, reaching its destination in one second, if automobile engineers were only as bright as computer scientists. Others have said we would be driving $25 cars that get 1,000 miles to a gallon if they were only designed by computer scientists instead of by automobile engineers. But the analogy should not be stretched too far. An advocate of software reliability might say seatbelts and bumpers are not intended to protect drivers from design errors but from their own errors, or bad driving; in software the analogous problem is designer error. If defects are discovered, cars are recalled and defective parts replaced. Some software products that update themselves multiple times a day crash anyway because analogous seatbelts and airbags in software are a luxury.

The defects Berger covered are more analogous to bad plumbing and crossed wires. Moreover, software developers may not even know all the components and functions in the software they deliver. Though perfect in terms of memory handling and buffer-overflow management, software can become a work of art during development, with no way to completely anticipate how it will perform under unknown circumstances.

I would like to see researchers of software code take a look at something I call “mind of software,” aiming for ways to make software more safe and predictable for common use.

Basudeb Gupta, Kolkata, india

Communications welcomes your opinion. to submit a letter to the Editor, please limit yourself to 500 words or less, and send to [e-mail].

© 2013 aCM 0001-0782/13/01