Browse Books

Reviewer: William George Frederick

The title of a book should indicate its contents. If “problem-solving” appears in the title, then the process of problem-solving should be an integral part of the text. Authors of introductory textbooks too often use catchwords glibly, without regard to their meaning. This does not relieve the authors of “problem-solving” books from their obligation to expend at least as much expository energy discussing the process of going from problem to program as they do detailing a programming language. All of these books use “top-down processing” as a metacognitive problem-solving strategy. Some are so bold as to present this as an “algorithm” for problem-solving, as if problem-solving were a finite, well-defined process. The better books, however, present the steps in problem-solving by top-down processing, while emphasizing that any such process is usually iterative or even recursive and programmers must constantly monitor their progress through these steps. A few even dare to mention “bottom-up” methodologies and state that real problem-solving should be a combination of both. None, however, really mention any other strategies, such as object-oriented design, or give problem-solving strategies equal time with the coding task. Reviewing these books has made me wary of books with “problem-solving” in their titles. While their titles do not necessarily say so, each book claims to be a textbook for some introductory course in Pascal and is thus subject to scrutiny as to whether it meets curricular demands and fits into the intellectual framework of the evolving discipline of computer science. According to the ACM Task Force on the Core of Computer Science, The purpose of the introductory course sequence is precisely this. The principal areas of computing—in which majors must develop competence—must be presented to students with sufficient depth and rigor that they can appreciate the power of the areas and the benefits from achieving competence in them [1]. As I read each preface, I determined the intended audience for its book. Table 1 illustrates the results of my search. My opinions in this review are based on how well each book meets these criteria of depth and rigor; I placed more emphasis on rigor. For the purpose of this review, I will pretend that I have to select one of these books for an introductory course in Pascal, evaluate the books according to their rigor and attention to problem-solving in programming, and rate them accordingly. While all the texts at least imply that they guide the reader through some “standard Pascal,” many go beyond any imagined standard to present other flavors of Wirth's original creation. Evidently, in spite of standardization efforts [2], confusion about what “standard Pascal” is persists (there are several variants). If this is a fair sample of introductory textbooks, then standardization issues are not being presented to many of our students. Some authors skirt standardization issues altogether and teach their imagined “standard” version of the language, which I have labeled “vanilla Pascal.” (See Table 2 for a comparison of language versions.) Table 3 summarizes the various methods these authors use to discuss algorithms, design, and Pascal syntax. For the sake of completeness, I have also included some size comparisons. The order in which Pascal constructs should be presented to beginning programmers often engenders heated debate. Not wanting to get sidetracked into this discussion or let my personal bias show, I have avoided this issue altogether. The sequence of topics is a matter of instructional and learning styles. As a consequence, any analysis of sequence of topics is left to the reader as a homework exercise and did not influence the subject evaluation given in the next sections. If supplementary materials for a textbook catch your fancy and influence your judgment of what text to purchase or adopt, Table 4 should interest you. Most of the items shown are free on request, provided the book is adopted as a textbook. Finally, Table 5 is an abbreviated list of appendices and reference materials included with these books. For the sake of brevity, I have only included those items that appeared in two or more of the books. I apologize to any authors whose originality I have penalized. Subjective Analysis The critical comments that follow discuss issues that occurred to me as I read each book. None is intended to be demeaning. They do, however, reflect my stubborn opinions and fundamental philosophy based on the tenets espoused above. As an aspiring textbook author myself, I am not insensitive to unfounded criticism in general; I present the comments that follow in the spirit of “egoless programming” for the express purpose of subjective comparison and in order to edify the reader. I found the books by Haiduk and Goldberg, Jefferies and Zerez, Leestma and Nyhoff, and Walker acceptable. Nance's text is marginal. The remaining books, by Gonzalez and Robbins, Harrow and Jones, Jones, and Nanney, are unacceptable. These purely subjective ratings are based on whether I would feel comfortable using each book as a text for an introductory programming course in Pascal. The discussion that follows is provided to support this decision. Problem-solving Can you learn magic by watching a magician perform__ __ Some authors claim that the indirect, learn-by-watching approach to teaching problem-solving is better than the direct method. Harrow and Jones state, “Indirectly, it will try to teach you quite a bit about problem solving. The indirect effect . . . will become clear as you proceed through the text.” Similarly, Jones says that “the second and third steps [in developing an algorithm] are the process of top-down analysis. We will illustrate the process by developing the algorithms and producing the program from the algorithms” (p. 109). Other authors, while they seem to use a top-down approach, never really take a clear stance or discuss their methodology openly. Gonzalez and Robbins give the impression that problem-solving is strictly a straightforward, linear process that never loops or uses recursion. Better textbooks, such as Nanney's, discuss top-down problem-solving by means of flowcharts or, like Jefferies and Zerez, emphasize the cyclical nature of problem-solving. Jefferies and Zerez discuss several design methodologies (including flowcharts and Nassi-Schneiderman). The emphasis Haiduk and Goldberg place on the communication skills necessary for programming and problem-solving is just as important; they warn novice programmers about the “rush to code” syndrome (p. 19). Walker, Leestma and Nyhoff, and Nance thoroughly demonstrate problem-solving with code production in detailed examples; Leestma and Nyhoff also discuss the software life cycle (p. 42). Modular Design It is not surprising that failure to deal with problem-solving properly has a proliferating negative effect on other topics in such books. For example, here is some advice on module design given to novice programmers: “Limit your module size to somewhere in the range of 50 to 100 lines in a program listing. We recommend . . . approximately 60 lines . . . a single sheet of standard computer printer output” (Gonzalez and Robbins, p. 253). “In concrete terms, when one step of an algorithm must be coded using more than one or two statements, a procedure statement should be used” (Jones, p. xii). “We will develop a technique in Chapter 3 that avoids widely separated BEGINs and ENDs. It is called `modularization'” (Jones, p. 48). “[Modularization is] `code grouping'” (Jones, p. 88). What about loose coupling and high cohesion__ __ The better books, however, emphasize an early introduction to modularization (procedures and functions) and warn against the abhorrent use of side effects. Walker pays attention to cohesion and is particularly adept at discussing the scope of local and global variables. Haiduk and Goldberg even discuss stubs, and Leestma and Nyhoff cover the proper use of structure charts. The Pascal Language Some important, fundamental language design issues in Pascal should be taught to this audience. Cooper's book on standard Pascal [2] should be required reading for all Pascal textbook authors. The audience for these books deserves a serious, critical, and careful discussion of Pascal. Lack of rigor in presentation of the language leads to lack of rigor in its use. I consider it an unforgiveable sin for an author to use a while-do as a repeat-until, as Gonzalez and Robbins, Harrow and Jones, Jones, Nanney, and Nance all do. These authors even fail to point out the fundamental difference between these two constructs. Rigor need not be sacrificed for pedagogy. Clear introductions to Boolean variables and control structures (see Leestma and Nyhoff, p. 98) and careful treatment of while-do and repeat-until loops do exist. Leestma and Nyhoff, Haiduk and Goldberg, and Walker emphasize the difference between the two kinds of loop, and Walker discusses loop invariants, exit conditions, and assertions. On the other hand, several authors present Pascal successfully. Haiduk and Goldberg discuss it from a programming language design perspective, and Jones compares Pascal with Modula-2. Beginning students need to understand the importance of some language formalisms via accepted methods, such as syntax charts or Backus-Naur productions, not with some author's own metalanguage introduced without definition (as in the Gonzalez and Robbins text). Data Structures and Files Pascal files are a difficult topic for any author. The real use of files is highly implementation-dependent. This is, however, no excuse for Nanney's refusal to deal with them thoroughly. The task is not impossible and Jefferies and Zerez, Nance, and Haiduk and Goldberg manage to present a thorough, rigorous discussion of file-handling issues. I was particularly impressed with Walker's explanation of file buffers. Introductory Pascal books need to deal with data structures of all types, since the real strengths of Pascal lie in this area. Data structures should be developed side by side with programs and the programming language, as in Haiduk and Goldberg's text. There should be more than just a cursory pass through some abstract data types—Haiduk and Goldberg, Walker, and Jefferies and Zerez do real justice to abstract data types. Leestma and Nyhoff's discussion of static versus dynamic allocation with pointers is particularly well done. Nonstandard Usages and Anthropomorphisms It is unfair to use nonstandard symbols in introductory texts. Harrow and Jones use flowchart symbols in a nonstandard way, omit flow arrows, and present flowcharts that have no exits. Jones includes nonstandard structure charts. Nanney even explains that the first five chapters of his text are taken from his FORTRAN 77 book. The Pascal in his book is written, like FORTRAN, in upper case with few identifiers over six characters long—a very unusual style. He even includes a FORTRANesque discussion of carriage-control characters in the output statements. Harrow and Jones's comment “The computer knows not to `fall into' the subprogram” (p. 107) is a typical anthropomorphism. Structured Programming Nance provides a clear discussion of the structured programming issue, while Harrow and Jones confuse style considerations with structured programming. Jones offers a rather strange list of seven basic instructions, presumably found in any general-purpose computer language, that he refers to as “the basic building blocks of computer programs.” Is the following any better__ __ “Structured programs do not use the GO TO statement, which is popular in some computer languages. For that reason, structured programs are sometimes called `GOTO-less' programs” (Nanney, p. 71). Interactive Design and User Interfaces All introductory texts could pay more attention to interactive design and user interfaces, as Jefferies and Zerez and Leestma and Nyhoff do in their texts. I find it remarkable that Leestma and Nyhoff fail to recognize interactive programs and Nanney ignores the user interface by displaying programs with no prompts (p. 81). Miscellaneous Because of space restrictions, I have only presented a few of the issues that occurred to me as I read these books. Kudos still needs to be given for Jefferies and Zerez's discussion of testing in depth, and their good input validation techniques; the style considerations in Jefferies and Zerez, and in Leestma and Nyhoff; Haiduk and Goldberg's structured walkthroughs and self-tracing; and Leestma and Nyhoff's carefully planned, integrated presentation and their good discussion of complexity. Summary and Editorial Comments My personal bias is that almost all introductory programming textbooks could stand a little more expository fat. I do not mean the “introductory calculus by the pound” syndrome of application and exercise overkill, but serious discussion of the fundamental issues of computer science that lays the foundation for possible future study in the discipline. That is not to say that we should segregate books and students into major versus non-major categories. We have done enough of that in course design. It is no wonder that students with one introductory computer science course under their belts still think of our discipline as programming. Prospective authors of introductory Pascal books need to provide all students in their intended audience with a clearer understanding of the theory, experimentation, and design that are vital to the discipline of computer science [1]. The topics listed by Denning et al. need to be integrated in all of the books reviewed above.