In his letter to the editor “Who Pays When Autonomous Fails?” (Nov. 2015) on Keith Kirkpatrick’s news story “The Moral Challenges of Driverless Cars” (Aug. 2015), Hans Grünberger attacked my proposal for ethics review boards (http://for.tn/1NHHU1s), implying I intend certification by such boards as a mechanism for shielding software companies and vehicle manufacturers from liability for the inevitable property damage, injuries, and deaths that will result from even the best-designed autonomous vehicles. This mischaracterizes my beliefs and my proposal.
I did not (and do not) intend such boards to be a shield. On the contrary, software companies and vehicle manufacturers should be liable for the mishaps, great and small, of their products (they will then price accordingly). But the necessary ethical decisions will either be made by commercial interests in a vacuum, as generally happens today, or a way will be found to include the public interest and professional expertise, as in the mechanism I proposed—review boards comprised of manufacturers, lawyers, ethicists, and government entities. Likewise, in a related area—the basic safety of these vehicles—government regulation is necessary (http://huff.to/1MWByHW), and I testified to this effect (http://bit.ly/1Rn2Wlt) before the California Department of Motor Vehicles on January 2015, to the likely dismay of the automaker and Google representatives in attendance.
Jonathan Handel, Los Angeles, CA
Start with a Dependable Publishing Schedule
In their column “Should Conferences Meet Journals and Where? A Proposal for ‘PACM’ ” (Sept. 2015), Joseph A. Konstan and Jack W. Davidson proposed a journal series, to be called Proceedings of the ACM, that would include papers from the proceedings of ACM’s most prestigious conferences, recognizing conference papers are viewed by some as second class when compared to journal papers. Supporting the proposal, the column said many scientists prefer conferences due to their up-to-date take on research and that journal limitations (such as the slowness of publishing) no longer trouble potential authors. Merging both proceedings and journals thus seems a natural approach to balance the computer science community’s competing interests.
Please write small, simple blocks of code and save yourself having to worry about naked braces.
A first step in this direction could instead be to reduce the overly long evaluation response schedules characteristic of iconic CS journals by establishing rigorous deadlines on the revision and editing process, from submission to publication or rejection. In my limited experience, the slow speed of journal publishing is indeed still an issue. Authors are often motivated to submit their papers to conferences just because of their shorter and more certain response times. If this assumption is correct, reducing evaluation response and editing times would initially alleviate, if not ultimately solve, the issues Konstan and Davidson outlined in proposing PACM.
Natale Patriciello, Maranello, Italy
Hold the Braces and Simplify Your Code
A. Frank Ackerman’s letter to the editor “Ban ‘Naked’ Braces!” (Oct. 2015) actually frightened me. The problem it described—code blocks so long and complex it is difficult for even expert programmers to determine which brace closes them—is certainly an issue, but the proposed solution would not leave the code any less complex.
When dealing with legacy code, maintainers can add annotations to a long method’s closing brace, as described, to help them navigate, but this should never be necessary in new code.
Modern code-writing techniques encourage small and only minimally nested blocks. See Robert C. Martin’s Clean Code chapter 3 (Prentice Hall, 2009) for a good explanation and justification. According to Martin, and others, a function or method spanning more than a few lines is too much for an average programmer to absorb and understand quickly, especially in the context of a larger system, and should be refactored for simplicity. Blocks nested more than two levels will not fit in a short, readable function and should thus be refactored to decrease depth. Programmers who follow these practices cannot possibly lose track of closing braces and will not then need to mark them up.
I make a living reading and trying to understand unnecessarily complex code, and follow Martin’s philosophy. If one writes code complex enough to require annotated closing braces, annotating those braces will not make the code less complex.
If you are a programmer, please write small, simple blocks of code and save yourself having to worry about naked braces. And if your habits run too deep, please do not encourage them in others, especially beginners.
Jamie Hale, Markham, Ontario, Canada
A. Frank Ackerman’s letter to the editor (Oct. 2015) recommended tagging each construct terminator with a comment indicating which construct it terminates. This wise practice was carried further in the design technique described in the book Principles of Program Design (Academic Press, 1975) and the paper “Constructive Methods of Program Design” (LNCS 44, Springer, 1976). Each sequence, selection, and iteration control construct is named. The name is prefixed to start and end markers and, in a selection, to each alternative. Ackerman’s coding example might thus be expanded to the following skeleton:
Such a discipline not only avoids simple errors. As Ackerman hinted, it also improves the program by tying its code closely to its design.
Michael Jackson, Milton Keynes, England
The Hypothetical 5% Expert Programmers
Jack Ring’s letter to the editor “Give Me the 5% Capable of Incisive Critique” (June 2015) downplayed the concerns I raised in my earlier letter “The Case of the Missing Skillset” (Apr. 2015) on Michael Walfish and Andrew J. Blumberg’s article “Verifying Computations without Reexecuting Them” (Feb. 2015). The letter said all IT management needs is a certain “… 5% of the workforce at the level of expert critic …,” a statistic unsupported by any reference. Knowing its source might help us understand the deductive process that led Ring to this particular percentage. The letter further said companies need “… critical attitude and a tool that tells them whether a program or combination of programs violates established rules …” This is beside the original point about a general lack of availability of capable expert programmers rather than the availability of automated tools.
To be practical, the letter’s claim would have to satisfy three requirements: a “critical attitude,” something no one would argue against, though an overly critical attitude can potentially cause the demise of an organization; a tool; and “established rules.” While academic tools for formal verification are readily available, an implied assumption is there is a certain set of established rules that would be common to every type of software project. Moreover, these rules would be unlike the rules traditionally enforced by compilers, linkers, or associated virtual machines. It would again be nice see a reference to a formal proof demonstrating the universality of this hypothetical set of rules for all software projects.
In case this principle is indeed not universal but rather project-specific, programmers would have to discover and write them in some formal language from user requirements. It would be only after such a step that a tool could be used for formal verification. Moreover, even after the tool would identify errors, the cycle would begin again, with programmers correcting the code, re-verifying, and so on. All these activities cost time and resources, which are always in limited supply. It also proves the point I made in my original letter—that there are not enough programmers with the skills needed to write efficient and verifiable parallel programs.
The letter’s hypothetical work setting could therefore possibly involve extended development time, an inflated budget, and delayed projects, factors all known to contribute to an organization’s potential failure. Most small-to-mid-size software companies cannot afford such a development life cycle. To the best of my knowledge, the only types of organization that might sustain it would perhaps be an academic institution, research-focused enterprise, or company involved in real-time or safety-critical applications. Perhaps we should therefore take the time to re-evaluate and revise the ACM/IEEE computing curricula to ensure a plentiful supply of future expert programmers trained in these areas.
Muaz A. Niazi, Islamabad, Pakistan
Join the Discussion (0)
Become a Member or Sign In to Post a Comment