The Dream of a Common Language: The Search for Simplicity and Stability in Computer Science Education

1. The drive to connect. The dream of a common language. — Adrienne Rich “Origins and History of Consciousness” The Dream of a Common Language (1974) The Dream of a Common Language:The Search for Simplicity and Stabilityin Computer Science Education Eric RobertsDepartment of Computer ScienceStanford University SIGCSE 2004Norfolk, VirginiaMarch 4, 2004

2. — Engraving of Scylla from Bulfinch’s Age of Fable (1855) The Twin Perils of Complexity and Instability • Complexity. The number of programming details that students must master has grown much faster than the corresponding number of high-level concepts. • Instability. The languages, libraries, and tools on which introductory computer science education depends are changing more rapidly than they have in the past.

3. CC2001 on the Problem of Complexity The number and complexity of topics that entering students must understand have increased substantially, just as the problems we ask them to solve and the tools they must use have become more sophisticated. An increasing number of institutions are finding that a two-course sequence is no longer sufficient to cover the fundamental concepts of programming. — Computing Curricula 2001

4. Essential and Accidental Complexity To see what rate of progress one can expect in software technology, let us examine the difficulties of that technology. Following Aristotle, I divide them into essence, the difficulties inherent in the nature of software, and accidents, those difficulties that today attend its production but are not inherent. . . . The complexity of software is an essential property not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. — Fred Brooks “No Silver Bullet” IEEE Computer, April 1987

5. Accidental Complexity Has Become a Crisis My fundamental thesis in this paper is that the computer science education community must find a way to separate the essential characteristics of object-oriented programming from those accidental features that are merely artifacts of the particular ways in which technology is implemented today. If we succeed in doing so, we can eliminate much of the inessential complexity and instability that plague computer science education today, which will allow more time to cover the essential elements of the subject matter. — SIGCSE Proceedings

6. An Illustrative Example: AP Computer Science • The AP Computer Science (APCS) program was introduced in 1984 using the language Pascal. • In 1995, the College Board announced that the APCS exam and course would change to C++. This transition was implemented in 1998-99, with the first C++ exams given in May 1999. • Two years later, the College Board announced that the APCS program would move to Java in 2003-04. The recent changes have been hard on high schools, forcing some to drop APCS.

7. original current Java C++ C++ Java (after minor updating) Skeptical Voices on the AP Change Pascal, the              AP language, is compact and designed around a small, coherent set of principles.         , in contrast, was designed to meet industrial rather than pedagogical goals. . . . At the very least, teachers and students will be forced to work with an enormously complicated tool, large portions of which will be mysterious to them. These mysteries of the language will inevitably rear their heads as students write and debug programs, and there is little experience with or understanding of how much of          a teacher needs to master in order to use it as a teaching tool. — Letter opposing the change in the CSAP Communications of the ACM, June 1995

8. 1536 pages 911 pages 274 pages 266 pages The March of Progress

9. An Even More Sobering Thought There are more public methods in the java and javax package hierarchies than there are words in Jensen and Wirth. The amount of text once deemed sufficient to teach the standard introductory programming language is thus no longer sufficient for a full index of the operations available today. — SIGCSE Proceedings

10. Sources of Java’s Instability • The vitality of the discipline. The number of people contributing to Java’s evolution is orders of magnitude larger than was true in Pascal’s day. As a result, more proposals for change are likely to occur within a given period of time. • The economics of proprietary languages. Pascal—as a language—was in the public domain. Java and C#, by contrast, are each under the control of a single vendor. Economic incentives for those vendors expose their user communities to the vicissitudes of the market. • Unintended consequences of encapsulation. There are reasons to believe that encapsulation—one of the core strengths of object-oriented programming—may in fact encourage instability by making it harder to overcome perceived shortcomings in existing APIs.

11. A Simple Illustration To illustrate the problem, think about how you would teach students to modify the method public void paint(Graphics g) {    g.drawString("Hello", 200, 100); } so that the string "Hello" is centered horizontally at the point (200, 100).

12. A Simple Illustration Writing the code isn’t particularly hard. All you need to do is use the FontMetrics class to compute the width of the string and subtract half that width from the x-coordinate: public void paint(Graphics g) { FontMetrics fm = g.getFontMetrics();    g.drawString("Hello", 200 - fm.stringWidth("Hello") / 2, 100); } The question is how to generalize this operation.

13. A Simple Illustration What you’d like to do is add drawCenteredString to the Graphics class and then code the method like this: public void paint(Graphics g) {    g.drawCenteredString("Hello", 200, 100); } Unfortunately, you can’t add drawCenteredString to the Graphics class because it is part of the java.awt package and therefore outside of your control. It is also difficult to adopt what seems to be the obvious object-oriented approach, which consists of subclassing Graphics so that the new subclass includes drawCenteredString. The problem with this strategy is that the standard AWT and Swing component classes create the Graphics objects, and it is hard to get them to create objects of your subclass instead.

14. Students, however, must understand why you write g.drawString("Hello", 200, 100); but drawCenteredString(g, "Hello", 200, 100); A Simple Illustration In the end, what most Java programmers end up doing is creating a static drawCenteredString method that takes the Graphics object as an explicit argument, like this: public static void drawCenteredString( Graphics g, String str, int x, int y) {    FontMetrics fm = g.getFontMetrics();    g.drawString(s, x - fm.stringWidth(s) / 2, y); }

15. But What If You Really Want Java to Change? • You could try to get Sun to make the change. Sun has established the Java Community Process to manage changes to the language. If you were passionate about some missing feature, you could try to get Sun to accept it for a future release. • You could create your own APIs. The alternative to having Sun introduce the changes is to create your own API hierarchy that incorporates your wish list. Indeed, many of the APIs that are now in Java, including Swing and a variety of more recent packages, got their start in this way. The critical point to recognize is that both of these strategies are inherently destabilizing.

16. The Looming Crisis Beset by the twin forces of complexity and instability, computer science education today faces an increasingly difficult challenge that threatens to become a crisis. The languages and tools we use today in introductory courses change much more rapidly than their predecessors in the early years of computer science. As a result, computer science textbooks and curricula have a shorter shelf-life and must be replaced every year or two. This instability, coupled with the increased detail complexity of the languages and tools, often makes it difficult to develop new materials before they become obsolete. — SIGCSE Proceedings

17. What we need instead is a community-sponsored effort to develop our own standards. In much the same way that the ACM Education Board has assembled task forces to develop curricular recommendations such as CC2001, it should be possible to convene a similar task force to define a simple, stable subset of Java and a set of supporting libraries that can meet the needs of our community. If such an effort involves broad representation from the affected constituencies and can attract sufficient funding, it will be of enormous value to the computer science education community. Where Do We Go from Here? I believe it is time to revisit the question of how we define the notion of “standard.” The principal advantage of a standard is that the authority behind the standard offers some guarantee of correctness and stability. As evidenced by the various ANSI standardization efforts, that guarantee can be effective when the body setting the standards represents the interests of the user community. The force of that guarantee, however, is compromised when the standard is subject to the economic interests of a particular vendor. . . . — SIGCSE Proceedings

18. The Java Task Force held its first meeting at the end of January 2004 and will describe its work at a special session tomorrow: Friday, March 5 10:45A.M. to 12:00P.M. Sheraton-Stratford The ACM Java Task Force In October 2003, the ACM Education Board approved the formation of a new task force with the following charter: To review the Java language, APIs, and tools from the perspective of introductory computing education and to develop a stable collection of pedagogical resources that will make it easier to teach Java to first-year computing students without having those students overwhelmed by its complexity.