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 letters@cacm.acm.org.
© 2013 aCM 0001-0782/13/01