Robert Dewar & Owen Astrachan
Brooks’ view, which I share, calls for “Hitching our research to someone else’s driving problems, and solving those problems on the owners’
terms, [which] leads us to richer computer science research” [ 12]. I will
return to problem-driven approaches later.
It would seem from the juxtaposition of amusing anecdotes regarding flawed software systems that Dewar would like to make the academic community and the larger computer science and software
communities aware that a simple change in attitude and programming
language in our colleges and curricula will help make the world more
secure and safe with respect to the reliable systems on which it
depends. Although software runs on computers it produces outputs
and effects that transcend computers. It was not a simple bug in
Moody’s computer system that caused constant proportion debt obligations to be incorrectly assigned the AAA rating. The model that
Moody used was likely incorrectly parameterized. Even if the flaw was
related to code, rather than to a model, Moody‘s correction of the
model did not lead to a change in the AAA rating as it should have
because of larger and more deeply entrenched financial and political
concerns. Standard and Poor’s model also assigned the AAA rating to
the same constant proportion debt obligations. Both services eventually lowered their ratings, but arguably these actions were insufficient.
Blaming the current economic crisis even in part on software
errors is more than a stretch. Similarly, Dewar notes that U.S. vice
presidential nominee Sarah Palin’s email account was compromised
and that a Web site was hacked, implying these are security failures
that might be fixed if only we didn’t use Java in our introductory
courses. Because Governor Palin used Yahoo mail for what appears to
be at least semiofficial business, her password recovery mechanisms
were based on publicly available information such as her birthday, and
her hacked email was posted on 4chan and Wikileaks: this is a case
study in social engineering rather than one in secure systems.
Dewar’s claim that Java is part of a “dumbing down” of our curricula has been echoed in other venues, notably by Joel Spolsky [ 15] and
Bjarne Stroustrup [ 14]. However, Stroustrup notes that it isn’t the language that’s a problem—it is attitude. He says, and I agree that:
“Education should prepare people to face new challenges; that’s what
makes education different from training. In computing, that means
knowing your basic algorithms, data structures, system issues, etc., and
the languages needed to apply that knowledge. It also means having
the high-level skills to analyze a system and to experiment with alternative solutions to problems. Going beyond the simple library-user
level of programming is especially important when we consider the
need to build new industries, rather than just improving older ones.”
These articles, like Dewar’s, associate Java with a “dumbing down”
of curricula. Spolsky specifically mentions the school at which I teach
as one of the new JavaSchools. He laments that our students are lucky
in that: “The lucky kids of JavaSchools are never going to get weird
segfaults trying to implement pointer-based hash tables. They’re never
going to go stark, raving mad trying to pack things into bits.”
We didn’t become a JavaSchool because we wanted to avoid segfaults, pointers, and bits. We use the same assignments and have the
same attitude we did when we used C++. We switched from C++ for
well-founded pedagogical reasons: Java is a better teaching language
for the approach we were using than C++. Note that I’m not claiming
Java is the best language for every program, but we spend much more
time in our courses dealing with the Brooksian essence of programming, algorithms, and software using Java rather than with the accidental aspects symbolized by the kind of cryptic error messages that
result from misusing the STL in C++. Our switch to Java was grounded
neither in perceived demands from industry nor in an attempt to
attract majors to our program, but in working to ensure that our beginning courses were grounded in the essence of software and algorithms.
We must work to ensure we attract motivated and capable students,
not because it is incumbent on us as faculty to train the next generation
of software engineers, but because it is our responsibility as educators
and faculty to encourage passion and to nurture and increase the
amazing opportunities that computing is bringing to our world. It is
highly likely that some programming languages are better for teaching,
others are better for Ajax applications, and the right flavor of Linux
makes a difference. But we shortchange our students and ourselves if
we live at the level of what brand of brace and bit or drill is best for a
carpenter. Instead, we should look for problems that motivate the study
of computing, problems that require computation in their solution.
Just as we cannot escape the essential complexity and difficulty of
developing software we cannot escape the essence of undergraduate
education. We each bear the burden of our past experiences in constructing models for education. In my case this is the grounding of
computer science as a liberal art, since my education began in that
realm. For others, computer science is clearly an engineering discipline and to others still it is a science akin to biology or physics. We
don’t need to look for which of these is the correct view; they are all
part of our discipline. The sooner we accept differing views as part of
the whole, rather than insisting that our personally grounded view is
the way to look at the world, the sooner we will make progress in crafting our curricula to meet the demands and dreams of our students.
Owen Astrachan ( email@example.com) is professor of the practice of computer science at Duke University and the department’s director of undergraduate studies for teaching and learning.
1. Andriole, S. J. and Roberts, E. 2008. Technology curriculum for the
early 21st century. Comm. ACM 51, 7. 27-32.
2. Brooks, F. 1987. No silver bullet: Essence and accidents of software
engineering. IEEE Computer 20, 4. 10-19. (Reprinted in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley, 1995.)
3. Brooks, F. 1996. The computer scientist as toolsmith II. Comm.
ACM 39, 3. 61-68.
4. Dijkstra, E. 1984 Keynote address at ACM South Central
Regional Conference. http://www.cs.utexas.edu/users/EWD/
5. Maguire, J. 2008. Bjarne Stroustrup on educating software developers. Datamation. http://itmanagement.earthweb.com/features/
6. Spolsky, J. 2005. The perils of JavaSchools. Joel on Software. http://