Liability and Braces
The Letters pages “Let the Liable
Pay” (Jan. 2016) included a letter
under that title by Jonathan Handel
on software liability followed by a
letter by Jamie Hale under the subhead “Hold the Braces and Simplify
Your Code” on ways to make code in
languages that use braces more readable. (These languages seem to follow a design principle emphasizing
ease of writing programs over ease of
reading them, so one would think developers interested in creating readable code would simply avoid using
such languages.)
Consider the software that flies
commercial airliners, in which an error can lead to significant liability, as
measured in billions of dollars, not
to mention the deaths of hundreds
of people. Producing and certifying
software of the required level of correctness, reliability, and robustness
is expensive, and airplane manufacturers seek ways to minimize that expense. For economic and safety reasons, both Airbus and Boeing use the
same braces-free language for their
software, and millions of people
trust their lives to it. It follows then,
that in a reasonable world, all software that should be correct, reliable,
and robust would be implemented
in such a language and to such standards. All safety-critical software, as
in cars, trains, and other vehicles,
and that operates medical devices,
should be required to be certified
to similar standards. Such software
also runs the Internet and all financial and commercial sites; for privacy
protection, all software on phones
and mobile devices; and, since software correctness cannot be guaranteed if run on an incorrect foundation, all operating systems correct
software would run on. That this is
usually not the case represents a serious condemnation of the software-engineering profession.
As for Hale’s recommendation to
write short blocks of code, while that
is good advice, the labeling of termi-
IAPPRECIATED PHILLIP G. Armour’s use of coupled pendulums as an analogy for software project management in his The Busi- ness of Software column “The
Chaos Machine” (Jan. 2016) but would
like to set the record straight on a few
technical points. Chaos is already be-
ing exhibited when Armour’s machine
performs smoothly, in the sense future
behavior is inherently unpredictable.
What happened when the machine
made a hop was not that it “hit a chaos
point” but apparently some “resonance
disaster” that caused it to exceed the
range of operation for which it was
built. Moreover, “turbulence” is not an
appropriate description in this context,
as it describes irregular movement in
fluid dynamics. Chaotic behavior does
not require three variables. The most
basic instance—the double pendulum,
with one rod hanging from the end of
another rod—involves only two vari-
ables. And the technological solution
for chaos is “control,” which applies to
software project management as well.
Setting a project in motion, even one as
simple as a single pendulum, then leav-
ing it unattended, is not a good idea. A
good case in point for how an unattend-
ed project can become chaotic is the
construction of the new Berlin airport.
Günter Rote, Berlin, Germany
Author’s Response:
Rote’s point is well taken. The word “chaos”
in general usage simply connotes disorder
and unmanageability, and I was using
that meaning rather than a more formal
characterization—something beyond both
my skill and my intent. Showing the device
generated a lot of interesting discussion in
the workshop—which was the point. And
as Rote graciously acknowledges, it was an
analogy for software-project management
rather than a physics experiment.
Phillip G. Armour, Deer Park, IL
We Are Our Machines
I was encouraged by Communica-
tions addressing such weighty issues
as “lethal autonomous weapon sys-
tems” through Moshe Y. Vardi’s Edi-
tor’s Letter “On Lethal Autonomous
Weapons” (Dec. 2015) and related
Stephen Goose and Ronald Arkin
“Point/Counterpoint” debate “The
Case for Banning Killer Robots” in
the same issue. Computing profes-
sionals should indeed be paying at-
tention to the effects of the software
and hardware they create. I agree
with those like Goose who say use
of technology in weapons should
be limited. America’s use of military
force is regularly overdone, as in Iraq,
Vietnam, and elsewhere. It seems like
making warfare easier will only result
in yet more wars.
ACM should also have similar discussions on other contentious public
issues; for example, coal-fired power
plants are probably today’s most
harmful machines, through the diseases they cause and their contribution to climate change.
ACM members might imagine they
are in control of their machines, deriving only their benefit. But their relationship with machinery (including
computers) is often more like worship.
Some software entrepreneurs strive
even to “addict” their users to their
products.
1 Computing professionals
should take a good look at what they
produce, not just how novel or efficient or profitable it is but how it affects society and the environment.
Scott Peer, Glendale, CA
Reference
1. Schwartz, T. Addicted to distraction. New York Times
(Nov. 28, 2015); http://www.nytimes.com/2015/11/29/
opinion/sunday/ addicted-to-distraction.html?_r=0
Author Responds:
I agree with Peer that
Communications should hold
discussions on public-policy issues
involving computing and information
technology, though I do not think
ACM members have any special
expertise that can be brought
to bear on the issue of coal-fired
power plants.
Moshe Y. Vardi, Editor-in-Chief
Chaos Is No Catastrophe
DOI: 10.1145/2897162