Communications of the ACM

Letters to the editor

Logic of Lemmings in Compiler Innovation

By CACM Staff
Communications of the ACM, May 2009, Vol. 52 No. 5, Pages 7-9
10.1145/1506409.1506412
Comments

I am deeply ambivalent about what I read in the contributed article "Compiler Research: The Next 50 Years" by Mary Hall et al. (Feb. 2009). On the one hand, its description of the field's challenges and opportunities evoke great excitement; on the other, the realities cast a discouraging pall on that excitement.

The practical adoption of useful research results is generally a slow process, taking up to a decade or more to achieve. In compilers, however, technology transfer has actually proceeded negatively.

It has been at least four decades since the idea first emerged that, besides translating to machine code, a compiler must be able to perform a second important function: automate detection of a large class of programming errors without the need for massive test suites. What followed was a series of programming languages and their compilers embodying this idea that at first (1970s and 1980s) software practitioners began to adopt at a typical rate.

But in the following decade, the industry reversed course, choosing C and later C++, which not only allow, but routinely require, highly unsafe methods scarcely above the assembly-language level, with huge regions of semantics that are explicitly disavowed as "undefined." Academic researchers and educators resisted this reversal for another decade, reasoning that safe languages would teach better habits, improve unsafe languages, and be all the more important when using unsafe languages. Eventually, however, they also succumbed to intense pressure and acquiesced to their role as industry minion.

Advocating for better language and compiler technology, I have almost never been rebutted by an argument beyond "It's what everybody is doing." It seems that the logic of lemmings is the only persuasive reasoning in the area.

The trend has now shifted toward pervasive use of scripting languages that abandon static safety altogether. The result is that developing large test suites is the only significant, viable means of ensuring quality and security. This has happened at the same time Internet attacks and concurrency have made these very qualities much more important. It is perhaps a difficult call whether better dynamic safety but worse static safety is good or bad but is certainly not a step forward.

The unpleasant truth is that almost the entire software community has resoundingly rejected the best research in compilers and languages, despite being well-proven as eminently practical for decades. Unless someone finds a way to dramatically change the attitudes of software developers, much of the exciting work Hall et al. envision for the next 50 years will be relegated to the role of academic exercise, as has happened for the past 40.

Rodney M. Bates, Wichita, KS

Authors' Response:

We agree with Bates that the software industry has been slow to adopt research ideas invented by the programming-languages and compiler communities.

Nevertheless, tools based on model checking are routinely used to verify Windows device drivers, and Google uses its MapReduce programming model for processing large-scale data sets.

Both model checking and MapReduce are based on research from the programming languages and compiler communities. We anticipate many more successful technology transitions of this sort in the future.

Mary Hall, Salt Lake City, UT
David Padua, Urbana-Champaign, IL
Keshav Pingali, Austin, TX

To Attract Women to Computer Science, Stress Love of Learning

I could hardly believe that a review article discussing "Women in Computing" (Feb. 2009) would quote a woman saying the best advice she received about how women should compete in the workplace is to "Look like a girl. Act like a lady. Think like a man. Work like a dog" (Jean Bartik, programmer for the Eniac computer). What precisely does each sentence mean? The whole statement sounds sexist to me, to say the least.

I deeply disagree with Caitlin Kelleher's statement "If we want young girls to choose to learn how to program computers, we need to deeply understand the kinds of programs girls will be motivated to create and design programming environments that make those programs readily achievable." This, too, makes no sense. Science is science, and the main motivation for doing science is the learning itself and the inner satisfaction and understanding knowledge delivers. If women cannot be motivated by learning and knowledge, they should not be doing science.

More important than making computing something that would please women so as to attract them is to educate them about the importance of science and knowledge and the inherent satisfaction they can bring any person.

Many of the "strategies" described as successful for the recruitment and retention of women in computing are, in my view, ways of reinforcing the existing bias against women in science (such as redesigning introductory CS courses to emphasize applications in areas of interest to women). This would succeed only at a superficial level, turning women into, perhaps, competent CS users.

Maria do Carmo Nicoletti
São Paulo, Brazil

To Learn Software Engineering, Study Application Logic

The question posed by the "The Profession of IT" Viewpoint "Is Software Engineering Engineering?" (Mar. 2009) by Peter J. Denning and Richard D. Riehle was much too narrow. The fact is that most of us aren't mathematicians, scientists, or engineers but rather accountants. I am a case in point, having spent half of my career working either directly on accounting/business applications or on the operating-system kernels underlying database servers.

Although the production of computer software does not typically resemble anything a mathematician would endorse or condone, it is nevertheless analogous to mathematics in that it serves as handmaiden to science, engineering, business, entertainment, and sometimes even mathematics. Therefore, the relationship between software engineering and the traditional engineering disciplines depends on which of these masters it happens to be serving, in other words, its context.

Paul E. McKenney
Beaverton, OR

Authors' Response:

Rather than take on the whole of software development, we restricted ourselves to whether software engineering is genuine engineering. Behind our question is the frequent sniping from other engineering fields that CS graduates cannot do basic engineering things (such as predict the failure modes of software and their attendant risks).

It is an interesting question whether augmenting software engineering with other aspects of software development would make it more like engineering. We doubt it would, but it is a great topic for a future column.

Peter J. Denning and Richard D. Riehle
Monterey, CA

Praise for the GT.M Database Engine

In his article "Parallel Programming with Transaction Memory" (Feb. 2009), Ulrich Drepper said that although transactions are familiar to database developers, their packaging is unfamiliar to systems programmers. Although he views software transactional memory (STM) as current research, the fact is that STM (embodied in the GT.M database engine, fis-gtm.com) is mature, proven technology in daily production use. GT.M provides so-called ACID, or atomic, consistent, isolated, and durable, transactions but in a schema-less database engine packaged as scalar and multidimensional associative memory (arrays) familiar to systems programmers. As the platform for the Fidelity Information Services Profile banking application (fis-profile), GT.M has been available for years, notably in banking and finance (tens of millions of accounts worldwide), running one of the largest, if not the largest, real-time core processing system at any bank anywhere in the world (tinyurl.com/asmque).

Drepper's sample function f1_1() he used to illustrate STM could be coded in GT.M in a procedural style familiar to systems programmers:

For code bracketed by TStart/ TCommit commands, the GT.M runtime system ensures the ACID properties, no matter how many processes execute the code at the same time. At TCommit, if no variables accessed by the transaction have changed since TStart, the runtime system commits the updates. If one or more variables has changed, the code automatically restarts from Tstart. Except for a small critical section internal to the runtime during TCommit, the processes run in parallel; to prevent "live locks" in the event the updates cannot be committed on the third try, the entire transaction is executed within a critical section on the fourth try. In the SMP multicore environments on which we benchmark Profile/GTM, we routinely observe linear to near-linear scalability (up to tens of processors/cores and hundreds of concurrent processes).

GT.M includes a compiler and language environment for the M (or MUMPS) language, so M and C are able to call each other, and the top-level program can be a C main(). Since the software is freely available under the AGPL v3 FOSS license (sourceforge. net/projects/fis-gtm), no technical or licensing barriers prevent creation of a preferred API to expose the underlying engine to a C programmer. Also worth noting is that the database engine uses a daemonless architecture and requires only ordinary user and group privileges to run.

GT.M's software transactional memory is a mature, proven technology, though more research is always welcome.

K.S. Bhaskar, Malvern, PA

Crediting SABRE's Sources

The "Economic and Business Decisions" Viewpoint "The Extent of Globalization of Software Innovation" by Ashish Arora et al. (Feb. 2009) referred to "...IBM's SABRE airline reservation..." There is indeed no such entity. SABRE is software developed by American Airlines that runs (in part) on IBM's Transaction Processing Facility operating system. TPF's predecessor, the Airlines Control Program, was developed from work done at American Airlines (and other organizations, including United Airlines) where the reservation system is called APOLLO. So there is a close association between IBM and SABRE, but SABRE is not an IBM product and never has been. John Schlesinger. London, U.K.

Authors' Response:

Computer industry histories like Martin Campbell-Kelly's From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, MIT Press, 2004, show that the SABRE system was a joint IBM-American Airlines project, developing the airline industry's first passenger-name record system. Similar systems were developed for other airlines by IBM. Our use of "IBM's SABRE airline reservation" was informal and consistent with the intent of the paragraph, namely that development of innovative systems typically involves close collaboration with lead users.

Ashish Arora, Pittsburgh, PA
Matej Drev, Pittsburgh, PA
Chris Forman, Atlanta, GA

Back to Top

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

---

No entries found