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

We should look
for problems that
motivate the study
of computing,
problems that
require computation
in their solution.

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.

 

References

1. Andriole, S.J. and Roberts, E. Technology curriculum for the early 21st century. Commun. ACM 51, 7 (July 2008), 27–32.

2. Brooks, F. No silver bullet: Essence and accidents of software engineering. IEEE Computer 20, 4 (Apr. 1987), 10–19. Reprinted in The Mythical Man-Month: Essays on Soft ware Engineering, Anniversary Edition, Addison-Wesley, 1995.

3. Brooks, F. The computer scientist as toolsmith II. Commun. ACM 39, 3 (Mar. 1996), 61–68.

4. Dijkstra, E. keynote address at ACM South Central Regional Conference, Nov 16, 1984; http://www. cs.utexas.edu/users/EWD/transcriptions/EWD08xx/ EWD898.html.

5. Maguire, J. Bjarne Stroustrup on educating software developers. Datamation (Dec. 9, 2008); http:// itmanagement.earthweb.com/features/article. php/3789981/.

6. Spolsky, J. The perils of JavaSchools. Joel on Software (Dec. 29, 2005); http://www.joelonsoftware. com/articles/ ThePerilsofJavaSchools.html.

 

Owen Astrachan ( ola@cs.duke.edu) is Professor of the Practice of Computer Science at Duke University and the department’s Director of Undergraduate Studies for Teaching and Learning.

Copyright held by author.

Calendar
of Events

July 15–17
engineering interactive
Computing systems,
pittsburgh, pa,
sponsored: siGCHi,
Contact: nicholas Graham,
phone: 613-533-6526,
email: graham@cs.queensu.ca

July 15–17
symposium on usable privacy
and security,
sponsored: siGCHi,
Contact: lorrie Faith Cranor,
phone: 412-268-7534,
email: lorrie@cmu.edu

July 19–23
international symposium on
software testing and analysis,
Chicago, il,
Contact: Gregg e rothermel,,
email: grother@cs.orst.edu

July 19–23
the 32^nd international
aCM siGir Conference on
research and development in
information retrieval,
Boston, Ma,
Contact: James allan,,
email: allan@cs.umass.edu

July 20–22
international Conference on
advances in social networks
analysis and Mining,
athens, Greece,
Contact: nicholas Harkiolakis,,
email: nharkiolakis@hau.gr

July 23–31
oregon programming
languages summer school,
eugene, or,
Contact: Matthew t. Fluet,
email: matthew.fluet@gmail.com

July 24–27
22^nd international Conference
on industrial engineering &
other applications of applied
intelligent systems, taiwan,
Contact: Moonis ali,
phone: 512-245-8050,
email: ma04@txstate.edu

July 26–31
the 46^th annual design
automation Conference 2009,
san Francisco, Ca,
Contact: andrew B kahng,
phone: 858-353-0550,
email: abk@ucsd.edu