The Dream of a Common Language:The Search for Simplicity and Stability

in Computer Science EducationEric Roberts

Department of Computer ScienceStanford University

SIGCSE 2004Norfolk, Virginia

March 4, 2004

The drive to connect. The dream of a common language.Adrienne Rich“Origins and History of Consciousness”The Dream of a Common Language (1974)

—

• 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.

The Twin Perils of Complexity and Instability

Engraving of Scylla fromBulfinch’s Age of Fable (1855)

—

CC2001 on the Problem of Complexity

Computing Curricula 2001—

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.

CS101I

Introduction to Programming

CS102I

Object-Oriented Programming

CS103I

Data Structures and Algorithms

CS111I

Programming Fundamentals

CS112I

Objects and Data Abstraction

Essential and Accidental ComplexityTo 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

—

Accidental Complexity Has Become a Crisis

SIGCSE Proceedings—

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.

• 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.

An Illustrative Example: AP Computer Science

The recent changes have been hard on high schools, forcing some to drop APCS.

Skeptical Voices on the AP Change

Letter opposing the change in the CSAPCommunications of the ACM, June 1995

—

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.

C++

C++

currentJava

Java

(after minor updating)

original

The March of Progress

266 pages 274 pages911 pages

1536 pages

An Even More Sobering Thought

SIGCSE Proceedings—

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.

• 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.

Sources of Java’s Instability

A Simple IllustrationTo illustrate the problem, think about how you would teach students to modify the method

so that the string "Hello" is centered horizontally at the point (200, 100).

public void paint(Graphics g){   g.drawString("Hello", 200, 100);}

A Simple IllustrationWriting 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.

A Simple IllustrationWhat 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.

A Simple IllustrationIn 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);}

Students, however, must understand why you writeg.drawString("Hello", 200, 100);

butdrawCenteredString(g, "Hello", 200, 100);

• 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.

But What If You Really Want Java to Change?

The critical point to recognize is that both of these strategies are inherently destabilizing.

The Looming Crisis

SIGCSE Proceedings—

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.

Where Do We Go from Here?

SIGCSE Proceedings—

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. . . .

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.

The ACM Java Task ForceIn 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.

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 510:45 A.M. to 12:00 P.M.

Sheraton-Stratford