SIGCSE '17: Proceedings of the 2017 ACM SIGCSE Technical Symposium on Computer Science Education
Educators, researchers, politicians, tech companies, and others continue to advocate for the importance of K-12 students learning computer science in our increasingly tech-driven society. One way school districts in the United States address this ...
SIGCSE 2023: Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 2
This workshop will introduce participants interested in teaching a full-term computer science ethics course to the tools and techniques of using science fiction to teach that course. The workshop will consist of three hourlong parts, each of which will ...
SIGCSE '15: Proceedings of the 46th ACM Technical Symposium on Computer Science Education
Many instructors and institutions offer research experiences and training in computing research methods. However, in a national survey, we find that undergraduate students rate their computing research experiences lower than students in other STEM ...
This debate grew out of a controversy surrounding a talk, “On the cruelty of really teaching computer science,” presented by Edsger Dijkstra in conjunction with the 1989 ACM CSC/SIGCSE Symposium held in February, 1989, in Louisville, KY. In his talk, Dijkstra challenged some of the basic assumptions on which course content and instructional approaches are based, and he stirred considerable controversy about a number of aspects of the teaching of computer science. The talk, which appears as part of this debate, prompted responses from W. L. Scherlis (Carnegie-Mellon University), David L. Parnas (Queen's University, Kingston, Ont., Canada), M. H. van Emden (University of Victoria, Victoria, B.C., Canada), Jacques Cohen (Brandeis University), R. W. Hamming (Naval Postgraduate School), Richard Karp (University of California, Berkeley), and Terry Winograd (Stanford University).
Dijkstra's talk raises a number of important issues in a highly provocative way. He argues that the computer represents a “radical novelty in our history” and then presents some of the educational and scientific consequences of this novelty. He expresses serious concern over the failure of education in general to “prepare the next generation for the phenomenon of radical novelties” and presents a number of different views as to how this shortcoming has affected computer science in particular, where, he asserts, the computer is not appreciated for the radical novelty that it is, and many of our approaches to teaching and practicing computing (programming in particular) are designed for “hiding or denying the frightening unfamiliar.”
Unfortunately, while a number of the issues raised by Dijkstra merit further scrutiny and reevaluation, the paper is full of gross generalizations, disparaging remarks concerning those (such as the business community, the military, and the “educational business”) whose orientations are not consistent with his own, and unsubstantiated criticism of areas of research and practice (such as software engineering) that Dijkstra apparently views as having little merit. In fact, Dijkstra's demonstrated lack of tolerance for the views, orientation, and activities of others unfortunately but understandably contributes as much as the technical content to the controversy surrounding his comments. These biases are unworthy of a scientist of his stature.
Each of the respondents focuses on different aspects of Dijkstra's comments. Most agree that the airing of issues stemming from Dijkstra's comments will be beneficial to the discipline. Parnas agrees with most of Dijkstra's remarks and focuses his response on the dismissal of the term “software engineering” and the denunciation of software testing. Scherlis agrees with the “overall thrust of Dijkstra's conclusion” concerning the importance of formal methods and the need to teach these methods to students of computing from the very beginning. He concentrates on some of the particulars of Dijkstra's arguments concerning modes of thinking for problem solving, difficulties posed by the range of scale of software systems, and the problems associated with formalization in software development.
Van Emden takes issue not with Dijkstra's idea of having “students derive programs from logic specifications into an unimplemented language,” but with the notion that this work can be done effectively in a pristine environment where students have not had an opportunity to have “messed around with programs that run or fail.” Cohen also agrees with the basic conclusions of the paper, but finds the extreme, uncompromising positions espoused devoid of “realistic constructiveness .”
Hamming, Karp, and Winograd challenge some of the fundamental tenets expressed by Dijkstra, and their responses raise the level of the debate to a point more appropriate to the original comments. Hamming challenges the view of mathematics that Dijkstra ascribes to the programming process and cites other fields of “human activity” that are also characterized by large, radical changes. He documents a number of errors produced by Dijkstra's extremism but argues that reformers must be extreme to achieve their goals. It is conceivable, however, that the extremism and narrow-mindedness exhibited in Dijkstra's comments will not in fact further the cause, but will make it more difficult for more reasoned arguments favoring similar positions to be heard.
Karp challenges Dijkstra's premise that equates software development with a large-scale application of logic and his proposal that an introductory course in programming should primarily be a course in formal mathematics completely free of program testing. He argues quite effectively and realistically that “formal proof and formal specification are not among the most promising avenues toward getting useful and dependable results from computers.” He agrees that many of Dijkstra's concepts, “if leavened with a bit of common sense,” are well worth conveying, and focuses his arguments on some of the more practical, commonsense issues. Winograd, too, challenges Dijkstra's basic premises, including his narrow views of computers (as simply symbol manipulators), of the task of the programmer (“to give a formal proof that the program he proposes meets the equally formal functional specification”), and of software engineering (which Dijkstra calls the “doomed discipline”).
Dijkstra addresses the comments of his debaters in a brief statement at the end of the debate. He fails to acknowledge what is, in my opinion, the major problem with his original comments. Large numbers of computer scientists have devoted a significant portion of their careers to the ongoing reevaluation and revision of the computing science curriculum and instruction techniques. This nontrivial exercise has been too little appreciated by many of our colleagues outside the field (and perhaps by some within it). Extreme positions, which advocate a single “right way” to deal with educational issues, will probably not prove particularly helpful in improving our methods. Such positions can be particularly damaging when espoused by leading researchers in the field, especially those looked to for more reasoned, balanced approaches to our problems.
Access critical reviews of Computing literature here
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]
Comments