persistence over time. A computer language also concerns communicating
with the computer.
Kamp seemed to conflate the formal syntax of a language with a variety
of presentation and communication
issues in programming environments,
rather than with the language itself.
His examples even demonstrated my
point; no matter what the formal syntax, contemporary tools can overlay
useful semantics, making it much easier for humans to express their ideas.
Why in the world would we want to enshrine the vagaries of human perception and cognition in the syntax of a
I also have reservations about many
of Kamp’s suggested improvements.
He clearly privileges “expression” over
“communication,” and his reference to
using color and multi-column layouts
is highly problematic. These concepts
make assumptions about the technical capabilities available to users that
are as likely to change as the perceived
technical constraints that led to the
syntax of C. Despite his intention to be
provocative, Kamp was also quite conservative in his technological assumptions, staying with two dimensions,
eschewing sound, ignoring handheld
technology, and generally expecting
WIMP interfaces on commodity PCs.
I find the biggest problem with programming languages involves understanding, not expression. I’m probably
typical in that I’ve read far more code
than I’ve written, most of it by strangers in contexts I can only guess. Many
of my toughest challenges involve unraveling the thoughts of these other
programmers based on limited evidence in the code. For the reader, adding color coding, complex nonlinear
texts, and thousands of glyphs means
only more cognitive load. It’s difficult enough to “execute C/Java/etc in
my head”; mapping complex, multicolored hypertext to formal logic only
makes it more difficult.
Kamp made a great case for why hu-
mans should never see programming
languages, just like they should never
see XML or RDF. They should express
themselves through environments that
promote communication by humans,
with the added ability for the machine
to generate correct code (in multiple
languages) as needed. While such
communication could be implement-
ed through a programming language,
the language itself would need features
not generally found in conventional
languages, including semantics (not
easy to define or express) that model
displays and layouts.
As desirable as McGrath’s vision might be, in
a trade where acrophobia is the norm, giant
leaps may be ineffective. So while others
work on the far future, I am happy to start
the stairs that will eventually get us there.
ton, CA); Graziano, Peter J. (Los Altos,
CA); Green, Michael D. (Los Altos, CA);
Greig, David A. (Cupertino, CA); Hayas-hi, Steven J. (Cupertino, CA); Mackie,
David R. (Ben Lomond, CA); McEvoy,
Dennis L. (Scotts Valley, CA); Treybig,
James G. (Sunnyvale, CA); and Wieren-ga, Steven W. (Sunnyvale, CA).
Armstrong also said, “Adding transactions is easy,” then sketched an implementation. While the implementation may be useful in the telecom
world, it does not handle the durability
provided by database transactions; see,
for example, Gray and Reuter. 3
Paul mcJones, Mountain view, CA
1. Bartlett, J.F. A ‘nonstop’ operating system. In
Proceedings of the Hawaii International Conference on
System Sciences (1978), 103–119.
2. Gray, J. Why Do Computers Stop and What Can
Be Done About It? Technical Report 85.7. Tandem
Computers, Inc., 1985.
3. Gray, J. and Reuter, A. Transaction Processing:
Concepts and Techniques. Morgan Kaufman, 1993.
4. Katzman, J.A. System architecture for NonStop
computing. CompCon (1977), 77–80.
credit Due for tandem’s
Hardware and os
Joe Armstong explained in his article
“Erlang” (Sept. 2010) how a programming language originally developed for
“building high-performance telecom
switches” is today used for a range of
high-availability, scalable applications,
but I would like to clarify two parts of
that explanation: The first was saying,
“This technique was used by Jim Gray2
in the design of the fault-tolerant Tandem computer.” Gray made major contributions at Tandem, but by late 1980,
when he joined the company, its fundamental hardware and operating system fault-tolerance techniques were
already established. Assigning credit
accurately for the various aspects of a
large and complex system design (such
as Tandem’s NonStop systems) may
be tricky, but Barlett1 and Katzman4
were key contributors to the hardware
and the operating system, respectively.
Bartlett’s paper acknowledged Dennis
McEvoy, Dave Hinders, Jerry Held, and
Robert Shaw as contributing to design,
implementation, and testing. Finally,
the co-inventors listed on the first patent granted on the Tandem system,
4,228,496, October 14, 1980, filed September 7, 1976, were: Katzman, James
A. (San Jose, CA); Bartlett, Joel F. (Palo
Alto, CA); Bixler, Richard M. (
Sunnyvale, CA); Davidow, William H. (
Atherton, CA); Despotakis, John A. (Pleasan-
McJones is correct in saying the
transactions described in my article are
nondurable. Database transactions with
ACID—atomicity, consistency, isolation,
durability—properties are provided by the
mnesia database included in the Erlang
distribution. The purpose of that section
was not to cover kinds of transactions
but to show the ease a particular type of
nondurable transaction involving an in-memory reversion to an earlier state could
on failure be accomplished through single-assignment variables.
Joe Armstrong, Stockholm
Communications welcomes your opinion. To submit a
Letter to the Editor, please limit your comments to 500
words or less and send to email@example.com.
© 2011 ACM 0001-0782/11/0200 $10.00
Coming Next Month in
Plug and Play Macroscopes
Seven Principles for
Understanding Scam Victims
Data Structure in
the Multicore Age
Also, the latest news on memristors,
teraGrid, PcAst, and interpreting
twitter’s data stream.