I enjoyed Thomas J. Cortina’s Broadening Participation Viewpoint "Reaching a Broader Population of Students through ‘Unplugged’ Activities" (Mar. 2015) on teaching students computer science unplugged, that is, without a computer, especially the "parity bit" game puzzle, but would like to suggest yet another way to show students computer science principles in action, by leading them through their school cafeteria.
Many computer science textbooks explore the concept of a last-in first-out stack by comparing it to the stack of plates in the cafeteria. The plate most recently pushed onto the stack is always the next one taken off the top. Only the topmost plate is visible and accessible, as a spring platform causes the other plates to sink below counter level. Yet the plate-stack analogy is only the tip of the iceberg when it comes to computer science principles; for example, a queue of diners waits to be served, first in, first out, so after the person in front is served, each other waiting person is promoted to the next position in the queue. The conveyor-toaster demonstrates pipelining and the multi-slice toaster batch processing. When preparing, say, a bacon cheeseburger, rules of parallel processing apply. The grill cook can fry the bacon and grill a beef patty in parallel but must wait for both processes to complete before assembling the cheeseburger, a serial step.
A cafeteria requiring shirts and shoes for service demonstrates Boolean logic. In fact, "Shirt and shoes required for service" and "No shirt, no shoes, no service" are equivalent due to De Morgan’s laws and the rules of inference. A student sitting at a table to eat is like a software process allocating and occupying memory. When students clear their table after eating to let someone else sit down, they are freeing memory.
The various levels of food storage are like different levels of data storage. Food readily accessible in the steam trays behind the counter is like RAM cache. Food waiting in the kitchen is like space on a hard drive. And food in a freezer is like tape storage or a compressed file.
Likewise, the cafeteria suggestion box reflects an asymmetric encryption scheme. The slot for inserting suggestions is, in essence, public-key encryption, since, in theory, no one else can peek at a suggestion once it is inside the box. The key to unlocking the suggestion box is a private decryption key.
Students can see all sorts of computer science theories, metaphors, and parallels in non-computing environments, quenching their thirst for knowledge and understanding even as they satisfy their hunger for, say, food, too.
Fred Murphy, Mountain View, CA
Turing Was No Gauss
Maarten Bullynck et al.’s comparison of Alan M. Turing and Carl Friedrich Gauss in their Viewpoint "Why Did Computer Science Make a Hero Out of Turing?" (Mar. 2015) reminded me of a delightful spoof article written in 1948 called "A Very Short History of Mathematics" by W.W.O. Schlesinger and A.R. Curtis of the University of Cambridge who read it at a meeting of the University’s mathematical society, then published it in Eureka, the society’s journal.
The article ran little more than two pages, but German mathematician Gauss merited a full paragraph, reading in part: "Gauss invented so many things that it just isn’t true … In fact, whenever anyone invented anything in the first half of the nineteenth century, Gauss had invented it twenty years earlier, and was still alive to tell him so …"
It is the world’s loss that Turing died so young, though it is difficult to imagine him publicly saying to any younger computer scientist "I was there before you," even if he had lived, like Gauss, to the age of 77. In terms of personal modesty at least, the two seem worlds apart.
Stephen Robertson, London, U.K.
When Software Is Not Protected by Copyright
Pamela Samuelson’s Legally Speaking Viewpoint "Copyrightability of Java APIs Revisited" (Mar. 2015), about the Oracle v. Google case now being considered for review by the U.S. Supreme Court, helpfully referred to certain considerations used in the Second Circuit’s influential Computer Associates v. Altai decision to determine when an element of a computer program is not protected by copyright but understated the significance of the time period to which those considerations are applied.
One such consideration, Samuelson emphasized, is whether the element was "dictated by external factors" (such as "compatibility requirements of other programs"), suggesting such a compatibility or interoperability requirement favors a holding that the Java APIs at issue are not protected. However, the purpose of Altai‘s "filtration" step, in which compatibility is one consideration, is to determine the scope of a program creator’s copyright from the outset by filtering out unprotectable program elements, so the step is applied as of the time of the program’s creation. At the time of creation of the software at issue in Oracle v. Google, the Java APIs were new, and their creation was not dictated by compatibility requirements of other programs, so this consideration argues in favor of, not against, their protection by copyright.
Under current case law, the need for compatibility/interoperability with currently popular programs and libraries remains a relevant factor in determining infringement, but as part of a fair use determination (such as was carried out in the Sega v. Accolade case Samuelson discussed), not as part of deciding which elements of a plaintiff’s program are protected by copyright at all. The Federal Circuit decision on appeal remanded the case to the district court for a new trial on fair use.
It is, however, also reasonable to ask why, if interoperability is an important enough factor in some cases to keep elements of a program from getting any copyright protection at all, that factor should be limited to interoperability at the time of the program’s creation. In light of the developments in software and programming that have made interoperability a practical necessity in many cases, it may be time for the Supreme Court to consider whether factors held relevant to protectability in Altai, including, but not necessarily limited to, interoperability, should be considered as of the time of alleged infringement, as well as the time of program creation, without the need for a full-blown fair use trial.
Allowing the infringeability of elements of a program to change due to developments subsequent to its creation would be a significant modification of copyright case law on its face but may represent the best accommodation of the statutory language and principles of copyright to a type of work—computer software—in which functionality plays a far greater role than in the literary works upon which the existing doctrine is based, and for which externalities like interoperability and changes in those externalities may substantially increase the benefits of copyright protection to program creators.
Marc K. Temin, Newton, MA
Author’s Response:
The Altai decision did not say one way or the other whether constraints on the plaintiff’s interface design had to exist at the time of creation of that software. Subsequent cases, most notably Sega v. Accolade, involved interfaces (such as for the Genesis platform) that could have been designed many ways initially by Sega. But when Accolade wanted to modify a videogame to run on the Genesis platform, its design decisions were constrained by the Sega interface if it was to achieve interoperability. The Ninth Circuit ruled the Sega interface was unprotectable by copyright law. The Federal Circuit was supposed to follow this Ninth Circuit precedent in Oracle v. Google but chose instead to misconstrue the case.
Pamela Samuelson, Berkeley, CA
Give the Client a Working Model
Leslie Lamport’s important Viewpoint "Who Builds a House without Drawing Blueprints?" (Apr. 2015) cited an eternal truth about the practice and craft of software engineering: that thought and planning must precede construction. But this analogy to architectural blueprints can be extended for the benefit of practitioner and client alike.
Designers of our built environment use blueprints and their modern digital equivalents to do much more than specify construction details for the trades. Models and blueprints are a communications tool that lets a client visualize and understand an architect’s proposed design while allowing the client to guide the design. However, a model that serves as a requirements-refinement tool is often missing from software-construction practice, at least in my experience. For most projects, the client is given nothing that yields meaningful understanding of a system’s behavior, due mainly to the extraordinary cost of providing a working model in advance of the system itself.
Lamport recommended mathematics as the best "language" for specifications. Yet most systems clients know less about formal logic than they do about probability, or little or nothing. Software utility to the client, outside the real-time domain, depends less on the precision illustrated by Lamport’s text-formatting example than on the business functions important to the client. Which of us would notice if a built bedroom was an inch smaller than the architect’s plan but would indeed consider legal action if the windows did not open?
Barry Needalman, Framingham, MA
Give Me the 5% Capable of Incisive Critique
Though Muaz A. Niazi’s Letter to the Editor "The Case of the Missing Skillset" (Apr. 2015) made a valid point concerning the "lack of the skillsets needed to write efficient and verifiable parallel programs," the problem of "how to bridge the gap between the software industry and the community of formal-methods practitioners" is not as daunting as he suggested. Employers do not need 100% of their software developers to be able to write the kinds of code Niazi envisioned. All they need is a critical attitude and a tool that tells them whether a program or combination of programs violates established rules. Just as many playwrights can learn from a single incisive critic, business people need only 5% of the workforce at the level of expert critic. Many of the other software developers will learn from interacting with them over time, while employers learn which 15% are no longer needed.
Jack Ring, Gilbert, AZ
Join the Discussion (0)
Become a Member or Sign In to Post a Comment