None of the three articles on the proposed Proceedings of the ACM—proposal, pro, and con—as coordinated by Joseph A. Konstan and Jack W. Davidson and introduced through their column "Should Conferences Meet Journals and Where? A Proposal for ‘PACM’ " (Sept. 2015) addressed what should be the fundamental concern for any publication: Who will actually read (and subscribe to) it? Would PACM, independent of the merits of the proposal for authors, have any value for ACM if it has no readers? I have some sympathy for academic researchers who produce high-quality conference papers yet do not get full academic credit for their work. But that is a problem with "academic scoring," and producing a publication whose sole value proposition is fixing that problem receives no sympathy from me.
The challenge for ACM should be how to deliver quality research to the more general ACM membership, not just the research community but practitioners who can actually apply the results of the research. Not every paper needs to have an immediate practical application, but I have read many conference papers that deserved exposure to a wider audience, particularly for papers I read 25 years ago that addressed problems only now becoming widely understood within industry. Communications has made substantial progress in this direction over the past few years, and ACM Queue should be considered a success. ACM must understand the era of making money with paper is over, and adding a publication whose only subscribers are potential authors and libraries with the money and space for "archival publications" represents a step in the wrong direction.
David Emery, Reston, VA
Authors’ Response:
Emery raises the question of how ACM can publish more content for a broad audience. We reject the trade-off between research and practice content as a false one. The PACM proposal does not create new content; it is an effort to recognize and systematically improve the quality of ACM’s best conference papers. These papers are already well read and well cited. With PACM, they will continue to be easily accessible in the ACM Digital Library.
ACM recognizes the importance of reaching practicing professionals. We continue to invest in Queue, are working to enhance practitioner content in Communications, and welcome suggestions for new publications for practicing professionals.
Joseph A. Konstan and Jack W. Davidson, ACM Publications Board Chairs
Who Pays When Autonomous Fails?
Gregory Mone’s news story "The New Smart Cities" (July 2015) was both alarming and enlightening, on smart things being for dumb people, while Keith Kirkpatrick’s news story "The Moral Challenges of Driverless Cars" (Aug. 2015) pondered what it means for paid scientists to dance before the golden idol of autonomous vehicles.
Consider, as quoted by Kirkpatrick, Patrick Lin et al. carefully sidestepped the core question of liability. Who would be held responsible if using an autonomous vehicle would result in damage or even death? The user, the vehicle manufacturer, or the involved software companies? It was convenient for Lin et al. to cite "legal and ethical challenges" instead of calling a stick a stick.
But wait, Jonathan Handel, the computer scientist turned lawyer mentioned by Kirkpatrick came to the rescue by proposing "ethics review boards," so we may yet have as a "procedural solution" certification by a board. Software companies would thus be off the hook by certifying their own products, and vehicle manufacturers would be off the hook by using certified software. Who would be left to actually take responsibility?
This might sound like legalizing manslaughter by different means. But review boards would be a tremendous help for companies like Google, Volkswagen, and Mercedes "pressing ahead for a fully autonomous vehicle," per Kirkpatrick, because there is money to be made in autonomous vehicles. Concerning cars, what avid driver would be interested in an autonomous vehicle that hints of mass transportation? And what else are autonomous vehicles but an effort to combine the efficiency of mass transportation with the luxury of personal transport? As for trucks, autonomous trucks are a missing link in a fully integrated logistics chain, and research in and infrastructure for autonomous vehicles would benefit them enormously.
Ethical shmetical … Given the economic implications (and scientists blind eye) this line of research probably is, I am sorry to say, "without alternatives."
Hans Grünberger, Wiesbaden, Germany
Give Me Code Access
Dorothy E. Denning’s Viewpoint "Toward More Secure Software" (Apr. 2015) mentioned "… very few users are in a position to inspect source code," making me wonder if she based this view on a "user survey" in an open source community like Linux groups or intended to communicate something else. I wonder because, as Microsoft critics often say, the company’s product-access policies lead to users being unable to look into their software’s (hidden) behaviors. On the other side, Linux proponents and other open source advocates usually claim users and developers alike can search for bugs and (unwanted) program routines in all kinds of Linux software. As a devoted Linux practitioner, I can say I have looked into the sources just a few times, usually during the compiling procedures of program executables; I am simply too preoccupied with other tasks to do that kind of inspecting more often. It looks to me the question of access is really about whether the end-user and developer communities are able to inspect the code, in light of their willingness, free time, and/or professional qualifications.
Miroslav Škorić, Novi Sad, Serbia
Author’s Response:
I was referring to the general user population, not communities of software developers. Most people have never written a program. But I cannot even imagine myself inspecting the tens of millions of lines of source code that generated the OS and applications running on my computer, despite my background in computer science and information security.
Dorothy E. Denning, Monterey, CA
Finite State Machines for UI Design Up Front
Arie van Deursen’s article "Testing Web Applications with State Objects" (Aug. 2105) elaborated on the utility of representing user interface (UI) elements by state machines or state objects for creating test scenarios. The finite state machine (FSM) is an excellent model for earlier development steps like requirement, design, and implementation. Behavior and process decisions, as described by van Deursen, should be taken much earlier in specifying the developed element. Developers and test specialists alike should then use the same model for implementing the application and its test scenarios.
The advantages of using finite state machines for development should be appreciated. The same FSM transitions set (state-transitions table or diagram) tends to be used throughout the process, from requirements to test, streamlining development. Content of distinct states creates a "layered FSM,"1,2 with requirements, design, implementation, and test layers for each state. Another advantage is the extensive set of structure and semantic rules for evaluating FSMs for correctness, in particular the event-state analysis introduced in Avnur2 that can also be used to construct an FSM with fewer defects in the first place. Using them, developers can bring FSM-based software to a very high level of quality even before the test phase. Additionally, FSM implementation can be automated through a code generator (such as the State Machine Compiler, http://smc.sourceforge.net/) or through a generic FSM class, as in Avnur,2 implementation. Reducing the scope of manual coding reduces defect rates even further.
UI design using state machines is not common, but for no good reason; all the general benefits described here apply to UI software as well; tools like state objects and articles like van Deursen’s will hopefully encourage it.
A development process that uses tools like FSM models to facilitate high-quality forward development even before testing is more correct by design and thus more effective than relying on test-fix cycles.
Arie Avnur, Chestnut Hill, MA
Ada, Not ADA
Thomas Haigh’s and Mark Priestley’s Viewpoint "Innovators Assemble: Ada Lovelace, Walter Isaacson, and the Superheroines of Computing" (Sept. 2015) mentioned "… when the language ADA was named in her honor …" The title of the ANSI/MIL-STD-1815A is "Ada Programming Language." It, and everything since on the subject, uses the capitalization of a person’s name, not an acronym.
Tom Moran, Saratoga, CA
Join the Discussion (0)
Become a Member or Sign In to Post a Comment