Download No Slide Title

The Dream of a Common Language:
The Search for Simplicity and Stability
in Computer Science Education
Eric Roberts
Department of Computer Science
Stanford University
SIGCSE 2004
Norfolk, 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)
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.
—Engraving of Scylla from
Bulfinch’s Age of Fable (1855)
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
CS101I
CS111I
Introduction to
Programming
Programming
Fundamentals
CS102I
CS112I
Object-Oriented
Programming
Objects and Data
Abstraction
CS103I
Data Structures and
Algorithms
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
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
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.
Skeptical Voices on the AP Change
Pascal, the original
current AP language, is compact and designed
around a small, coherent set of principles. Java
C++ , 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 C++
Java 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
(after minor updating)
The March of Progress
1536 pages
911 pages
266 pages
274 pages
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
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.
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).
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.
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 objectoriented 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 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);
}
Students, however, must understand why you write
g.drawString("Hello", 200, 100);
but
drawCenteredString(g, "Hello", 200, 100);
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.
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
Where Do We Go from Here?
IWhat
believe
weit need
is time
instead
to revisit
is athecommunity-sponsored
question of how we define
effort the
to
notion ofour
develop
“standard.”
own standards.
The principal
In much
advantage
the same
of way
a standard
that the
is
that theEducation
ACM
authority Board
behindhas
the assembled
standard offers
task some
forcesguarantee
to develop
of
correctnessrecommendations
curricular
and stability. As such
evidenced
as CC2001,
by the various
it should
ANSI
be
standardization
possible
to convene
efforts,
a similar
that guarantee
task force
cantobedefine
effective
a simple,
when
the body
stable
subset
setting
of Java
the and
standards
a set of
represents
supporting
thelibraries
intereststhat
of can
the
user community.
meet
the needs of The
our community.
force of thatIf guarantee,
such an effort
however,
involves
is
compromised
broad
representation
when the
fromstandard
the affected
is subject
constituencies
to the economic
and can
interestssufficient
attract
of a particular
funding,
vendor.
it will
. . be
. of enormous value to the
computer science education community.
— SIGCSE Proceedings
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.
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:45 A.M. to 12:00 P.M.
Sheraton-Stratford