Systems and Networking

Teaching effective problem-solving skills in the context of teaching programming necessitates a revised curriculum for introductory computer programming courses.

Programming has been described by many authors as the new Latin of the school syllabus, a kind of mental whetstone for developing minds. As such, it was assumed that students would develop their general problem-solving skills through learning programming. However, reports from teachers of programming and results from some empirical studies now suggest that the teaching of programming has created significant difficulties for high-school and university students, and has failed to catalyze the development of higher order thinking skills. What has gone wrong? Before reviewing the major points of the three articles that follow, I would like to highlight some of the challenges of both teaching and learning programming. The programmer's objective, for novice and expert alike, is first to specify a detailed plan that can be carried out. That is, the programmer has to decompose the initial task. This is not trivial: Many people are quite unable to say how they perform certain tasks. For instance, many students in introductory programming classes are unable to explain how they are able to select the smallest of a series of integers. Next, the programmer must map this plan into the constructs of the target programming language. There are two points to be made about this mapping process. First, for the process to be "clean," the programmer needs to have a very clear idea of the abstract plan and of the constructs available in the programming language. One study of novice programmers showed that many novices had very fuzzy notions about a programming language—substantial misunderstandings had occurred with regard to virtually every construct in the language. Second, task decomposition and program coding are not as neatly decoupled as we might think. A simple example: If arrays are not available in the target programming language, then a plan that assumes this capability would be badly flawed. A thorough knowledge of the facilities provided by the programming language is needed even at the stage of formulating the task plan. Debugging a program is similarly complex and demands a variety of skills, including an ability to coordinate information derived from sources such as error messages, the program plan, the program specification, and the actual code. The three articles in this special section address different aspects of the challenge of programming. John Anderson and Edward Skwarecki's "The Automated Tutoring of Introductory Computer Programming" demonstrates that intelligent computer-assisted instruction (ICAI) technology can be a more effective way of teaching introductory programming courses—for certain populations. Specifically, the authors discuss the pedagogical effectiveness of a Lisp tutor developed at Carnegie-Mellon University. Elliot Soloway's "Learning to Program = Learning to Construct Mechanisms and Explanations" challenges conventional wisdom by taking a fresh look at assumptions about the art of programming. Soloway advocates a more explicit approach to the teaching of problem-solving skills, which is based on the actual skills experienced programmers use in addressing real tasks. Recent experiments have suggested that the domain knowledge of experienced programmers is organized in a radically different way from the domain knowledge of novices; analogous results have also been reported for chess and music. In all cases, experts use larger chunks of knowledge. An important instructional question is how to bring novices up to the expert's level of domain knowledge. Aside from teaching details of the syntax and semantics of a particular programming language, Soloway argues, it is necessary to explicitly and concurrently explain why and how programs work, the goal of any given program, what plan segments are, strategies for decomposing tasks, rules that well-formed programs adhere to, and design strategies. If followed, this approach would produce several radically different types of programming courses. "Boxer: A Reconstructible Computational Medium," by Andrea A. diSessa and Harold Abelson, proposes a radically new kind of computational medium—one that would be highly tailorable, and able to accommodate a wide range of users, from a seven-year-old to an experienced nonprofessional. The authors suggest that students' difficulties may have more to do with the nature of programming than with teaching per se. They describe their current project, Boxer, which is an attempt to provide an environment for a wide spectrum of human activities. The central notion of Boxer is the metaphor of nested "boxes" organized in a hierarchy that gives novices access to explicit and detailed information about the computer environment, but allows proficient programmers to work at the highly abstract and implicit level that is natural to them. All three articles emphasize the need for sensitive experimentation for determining the effectiveness of innovative approaches to the teaching of programming. In the absence of strong and pervasive cognitive theories, it is important to carry out extensive evaluations of all such innovative approaches. We must find out from experience whether well-structured ICAI can be as useful and important as Anderson and Skwarecki suggest; or how we might be able to teach Soloway's high-level problem-solving skills effectively through programming; or how well seven-year-olds will be able to get along with the Boxer system, and for what range of tasks. Any mismatches between observations and expectations will hopefully suggest the next round of new languages and environments, and in turn motivate the next set of observations.