Carl Landwehr was right to suggest in his Viewpoint "We Need a Building Code for Building Code" (Feb. 2015) that there should be a building code for software. Lawmakers should thus re-examine the common practice of allowing warranty disclaimers for commercial software. The software development industry claims it is simply too difficult to build correct software. But such a position looks increasingly absurd. A smartphone derives most of its functionality from gigabytes of software, though it is regarded as a device; an inability to make calls or take photos is rightly covered by consumer-protection laws. Smartphones are only the most obvious case; innumerable consumer products, including televisions and automobiles, depend crucially on software yet are protected by warranties. The only software subject to warranty disclaimers is, incredibly, actual software products.
As a first step toward abolishing warranty disclaimers, lawmakers should make software companies liable for faults caused by egregious programming malpractice. The most obvious example is buffer overruns and, more generally, failure to validate input data, whether from a user or from a file. An example of the latter is when a program crashes due to one of the possibly thousands of fonts on the machine being corrupt. Passwords stored in clear and other gross lapses of security engineering should be explicitly forbidden. Never forget the astonishing case of the Diebold voting machine, as reported by Douglas W. Jones of the University of Iowa in 2003, saying, "The encryption key F2654hD4 is present, in plain view, in the source code."1
The most obvious example is buffer overruns and, more generally, failure to validate input data, whether from a user or from a file.
In addition to forbidding specific instances of programming malpractice, a software building code should include the obligation to use static analysis tools and other techniques to improve the practice of software development.
Lawrence C. Paulson, Cambridge, England
Verify a Computation by Checking the Result
The title of Michael Walfish’s and Andrew J. Blumberg’s article "Verifying Computations without Reexecuting Them" (Feb. 2015) suggested a much more practical problem than the one these authors actually solved. When most users want to verify a computation, all they really want to do is check the result. They are not asking whether the algorithm is correct or if every step of a computation was in accordance with the algorithm. They want to know if the computed result is accurate enough to satisfy their requirements. This is often much easier than computing the result and far easier than verifying the correctness of a program; for example, verifying that a computed square root is close enough to the actual root is far easier than computing the root. One need only multiply the result by itself and compare the product with the original number. Similarly, solving a set of equations may require a complex algorithm, but confirming that a proposed solution works is easy; one substitutes the values for the variables and evaluates the equations.
In general, the specification of a program is a predicate. If a program can evaluate the predicate, it can check the result. In many common situations, evaluating the predicate is a simpler process than finding the answer.
David Lorge Parnas, Ottawa, Canada
First Simplify Software
Vinton G. Cerf’s Cerf’s Up column "A Long Way to Have Come and Still to Go" (Jan. 2015) invited comments on progress in programming. Forty years of deliberately perpetuated excess complexity has caused great harm. Progress toward simplicity has been obstructed by anxieties about being simplified out of jobs, corporate revenue, and elite status. Computer languages used today are deficient compared with a 1973 design called "Prose" distributed within IBM based on each of the following seven simplicity-related criteria:
Flexibility of data structures;
Simplicity of expression. For example, a computation like 6 = count every state where populatn of some city of it > 1000000 requires at least twice those 14 tokens (words and symbols) when using today’s wide-purpose languages compared to what was operational in 1982. There is no enduring technical reason for using a wide-purpose technical language that fails to express this computation with comparable simplicity;
Generality of language applicability;
Modularity of fundamental information building blocks. Including iteration connections in the "atomic structure" of information is probably essential. They resolve a historical dichotomy between languages with flexible data and those with simple plural expressions;
Fluency of precise expression;
Durability of core language design; and
Potential for precise human-to-human communication. Simplification can extend the usefulness of precise language broadly into technical communication and education.
Workers and policymakers in software, education, cybersecurity, and public safety have shown almost no publicly visible aspiration to language technology by any of these criteria as advanced as was designed in the early 1970s at IBM and implemented for internal use a decade later at Digital Equipment Corporation. For more on these deficiencies, see "Inexcusable Complexity for 40 Years" at http://users.rcn.com/eslowry.
Students everywhere are taught how to arrange pieces of information by educators unaware of elementary pieces of information well designed for easy arrangement. Sound leadership could easily fix this deficiency. From airfoils to zippers, fundamental technological structures have received meticulous attention, but serious study of easily arranged information building blocks has been resisted for at least 30 years.
Thorough elimination of extraneous complexity can produce fluency, language generality, and convergence of core semantic design, especially the design of information building blocks, leading toward the practicality of an enduring lingua franca for technical literacy. Computer science curriculum planning would benefit from considering possible student reaction to learning about the deficiencies in current languages.
In its 2013 annual report, IBM reported 88.8% gross profit on $25 billion in software revenue. Complexity in software discourages customers from switching vendors, thus keeping these numbers high. This is just one example of the magnitude of incentives to keep the world ignorant of serious simplification.
Leadership tolerance for the effort to clarify these issues has seemed meager for decades, while the technical literature has ignored thorough simplification. IEEE-USA publicly acknowledges the long delay in simplification but in a muted way. There is thus an urgent need for organizations that value post-1974 competence in software simplicity to make their positions known.
Edward S. Lowry, Bedford, MA
Python for Beginners? Try Perl 6
Esther Shein’s news article "Python for Beginners" (Mar. 2015) tracked with the kind of articles on Python popularity I have been reading online for several years. Despite Python’s growing popularity, Perl has remained my scripting language of choice since 1993, even as I awaited Perl 6 (http://perl6.org/) to address the shortcomings of Perl 5. Perl 6 is usable today, and I have begun translating my latest Perl 5 code to Perl 6. I wonder what Shriram Krishnamurthi, the professor of computer science at Brown University quoted in the article, would think of Perl 6, since most, if not all, major Python shortcomings he mentioned are indeed addressed quite well in Perl 6.
Perl 6 would make an excellent replacement for Python as an introductory teaching language, whether in college or in middle school; I even recently proposed using it for an introductory scripting course in a summer science camp sponsored by the Okaloosa STEMM (Science, Technology, Engineering, Math, and Medicine) Academy (http://www.okaloosaschools.com/stemm/).
Tom Browder, Niceville, FL
Correction
The name "Blaise" inadvertently added [in brackets] in the context of the Pascal programming language in Esther Shein’s news article (Mar. 2015) was removed from digital versions of the article but was not caught in time to be removed from the print edition.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment