Sign In

Communications of the ACM

Letters to the Editor

Chaos Is No Catastrophe

View as: Print Mobile App ACM Digital Library Full Text (PDF) In the Digital Edition Share: Send by email Share on reddit Share on StumbleUpon Share on Hacker News Share on Tweeter Share on Facebook
Letters to the Editor, illustration


I appreciated Phillip G. Armour's use of coupled pendulums as an analogy for software project management in his The Business of Software column "The Chaos Machine" (Jan. 2016) but would like to set the record straight on a few technical points. Chaos is already being 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 instancethe double pendulum, with one rod hanging from the end of another rodinvolves only two variables. 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 leaving it unattended, is not a good idea. A good case in point for how an unattended project can become chaotic is the construction of the new Berlin airport.

Günter Rote, Berlin, Germany

Back to Top

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 characterizationsomething beyond both my skill and my intent. Showing the device generated a lot of interesting discussion in the workshopwhich 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

Back to Top

We Are Our Machines

I was encouraged by Communications addressing such weighty issues as "lethal autonomous weapon systems" through Moshe Y. Vardi's Editor'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 professionals should indeed be paying attention 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

Back to Top

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

Back to Top

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 terminator markers, which he dismissed as unnecessary, is still a good idea. The language used in commercial flight software requires terminating if statements with end if;, records with end record;, case statements with end case;, and so on. Many constructs can be labeled with a name that then appears in the terminator end loop Name;. This is because there is evidence block terminators are a common source of error, and such labeling reduces such errors, even for short blocks. Short terminators (such as a brace) are a greater source of error than long terminators (such as end), which is why braces are avoided. Safety and readability are designed into the language rather than as an afterthought.

The economic pressures to expand liability to more software would thus be expected to lead to a reduction in the use of languages with braces, along with an associated increase in readability.

Jeffrey R. Carter, Mesa, AZ

Back to Top

A Log Graph Too Far?

I really enjoyed George V. Neville-Neil's article "Time Is an Illusion Lunchtime Doubly So." (Jan. 2016) and am a big fan of his Kode Vicious columns as well. However, I could not fathom the intriguing figure (see it here) in the article, labeled simply "PTP log graph," nor could I find any reference to it in the text that might shed light on what property of the Precision Time Protocol it is supposed to illustrate. Not being an electrical engineer myself, I thought it might be something obvious to someone in the field, yet a friend with a Ph.D. in electrical engineering was equally flummoxed. It was such an interesting chart I am keen to understand what it meansif I can. Prof. Neville-Neil, can you enlighten me?

John Beresniewicz, Half Moon Bay, CA

Back to Top

Author Responds:

The PTP Log Graph in the figure showed the offset of a system clock that is not regulated by an outside time source (such as NTP and PTP). Without an outside time source, the clock wanders away from where we would expect it to be if the system's crystal oscillator was more stable, which it is not.

George V. Neville-Neil, Brooklyn, NY

Back to Top


1. Schwartz, T. Addicted to distraction. New York Times (Nov. 28, 2015);

Back to Top


Communications welcomes your opinion. To submit a Letter to the Editor, please limit yourself to 500 words or less, and send to

Back to Top


UF1Figure. PTP log graph.

Back to top

©2016 ACM  0001-0782/16/04

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from or fax (212) 869-0481.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2016 ACM, Inc.


No entries found