CS Education in the U.S.: Heading in the Wrong Direction?
4. Farrell, N. 2008. Boffins deride Java. The Inquirer. http://www.
5. Maloney, P. and Leon, M. 2007. The state of the national security
space workforce. http://www.aero.org/publications/crosslink/
6. McGuire, J. 2008. Who killed the software engineer? (Hint: It happened in college.) Datamation. http://itmanagement.earthweb.
7. National Air Traffic Services. NATS pioneers biggest ATC advance
since radar. http://www.nats.co.uk/article/218/62/nats_pioneers_
8. Oates, J. 2008. Moody’s to fix sub-prime computer error. The
9. USAF Software Technology Support Center (STSC). 2008. Computer science education: Where are the software engineers of tomorrow? Cross Talk. http://www.stsc.hill.af.mil/Cross Talk/2008/
Counterpoint: Owen Astrachan
Robert Dewar has graciously shouldered the task of castigating the language commonly used in introductory programming courses. Dewar,
like Edsger Dijkstra [ 13] and others before him, holds the language at
least partially responsible for, and decries the state of, computer science curricula; he then attempts to use the programming language as
a lever to move curricula in a particular direction. However, the lever
of the introductory programming language is neither long enough nor
strong enough to move or be responsible for our curricula. Attempts to
use it as such can generate discussion, but often more heat than light.
The discussion is often embroiled in fear, uncertainty, and doubt (aka
FUD) rather than focused on more profound issues.
There are definite elements of FUD in the arguments offered by
Dewar just as there have been by his predecessors in making similar
arguments. Whereas Dijkstra lamented “the college pretending that
learning BASIC suffices or at least helps, whereas the teaching of
BASIC should be rated as a criminal offense: it mutilates the mind
beyond recovery” we see Dewar noting that “It’s not impossible to teach
the fundamental principles using Java, but it’s a difficult task.” Dewar
and Dijkstra perhaps would like us to return to the glorious days of text
editors and punch cards rather than “fancy visual IDEs.” However, the
slippery slope of assumption that the new generation just doesn’t get it
leads to the Sisyphean task of pushing the pebble of language, be it
BASIC or Java, uphill against the landslide of boulders that represents
the reality of computer science. This is the case regardless of whether
we’re in Dijkstra’s world of 25 years ago, the world of 2009, or the
Skynet world of tomorrow—which is probably closer than we think.
I don’t mean to suggest that Dewar and Dijkstra are arguing for the
same thing. Dewar would like computer science programs to produce
well-trained software engineers who can build large complex reliable
systems. Dijkstra excoriated software engineering at every opportunity
fixing as its charter the phrase “how to program if you cannot.” Both
miss part of the bigger picture in the same way that Stephen Andriole
missed it in the July 2008 Communications Point/Counterpoint “Tech-
nology Curriculum for the Early 21st Century” [ 10]. In his Counterpoint,
Eric Roberts points out the flaw of “generalizing observations derived
from one part of the field to the entire discipline.” Computer science programs must embrace a far wider audience than software engineers
building secure systems. Many top programs are housed in schools of
Arts and Sciences rather than in Engineering, many have chosen not to
be accredited by CSAB/ABET Students may choose computer science
as a stepping-stone to law, medicine, philosophy, or teaching rather than
as a foundation for becoming a programmer or software engineer.
Schools like Georgia Tech are developing innovative programs to address the different needs of diverse audiences: students looking to
computer science as the basis for visual studies or biology rather than
preparing them for a software-oriented career. There is no one-size-fits-all solution to addressing the skills and knowledge needed to succeed
in these areas. Should we expect Craig Venter or Gene Myers to ask
computer science programs to include more computational biology because the demand for bioinformaticians exceeds supply? Will we be surprised if Ken Perlin asks for programs to embrace games and graphics
more than they do to ensure a steady supply of people interested in animation or computer-generated imagery? We are discussing the requirements and curricula of an undergraduate degree! Our programs
can certainly build a superb foundation on which students can continue
to gain knowledge and skills as they work and study in different areas,
but we should no more expect students to be expert or even journeymen than we expect our premed students to be able to remove an appendix after four years of undergraduate study.
As Fred Brooks reminded us more than 20 years ago, there is no
silver bullet that will solve the problems endemic to software development nor is there a panacea to cure the ills that may plague computer
science curricula and programs [ 11]. Studying more mathematics will
not make software bugs disappear, although both Dijkstra and Dewar
seem to think so. Dewar points out the need for “formal specification
and proof of correctness techniques” as foundational for software
development using Ada. Dijkstra tells us “where to locate computing
science on the world map of intellectual disciplines: in the direction of
formal mathematics and applied logic,” but pines for Algol rather than
Ada. Both miss Brooks’ point about the essential complexity of building software, the essence in the nature of software. In a wonderful treatise that has more than stood the passage of 20 years and in which he
presciently anticipated the tenets of Agile software methodologies,
Brooks claims that “building software will always be hard,” and that
this essence will not yield dramatic improvements to new languages,
methodologies, or techniques.
Brooks has hopes that the essential aspects and difficulties of software may be improved by growing software rather than building it, by
buying software rather than constructing it, and by identifying and
developing great designers. He differentiates between essential and
accidental aspects of software where accidental is akin to incidental
rather than happenstance. Changing programming languages, using
MapReduce or multicore chips, and employing a visual IDE in introductory courses address these accidental or incidental parts of software development, but these don’t mitigate the essential problems in
developing software nor in educating our students. As Brooks notes,
addressing these accidental aspects is important—high-level languages
offer dramatic improvements over assembly-language programming
both for software design and for introductory programming courses.