Iam 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 re-
alities 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 assem-bly-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
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 Kelle-her’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 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
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 math-
References:
Archives