The Parts of the Book

The book consists of eight parts and seven intermezzos. The parts focus on program design; the intermezzos introduce other topics concerning programming and computing. Figure~#figdependence#111> shows the dependence graph for the pieces of the book. The graph demonstrates that there are several paths through the book and that a partial coverage of the material is feasible. Parts~#partbasic#112> through~#partadvanced#113> cover the foudations of data-driven program design. Part~#partabstract#114> introduces abstraction in designs. Parts~#partrecursion#115> and~#partloops#116> are about generative recursion and accumulation. For these first six parts, the book uses a completely functional---or algebraic---form of programming. One and the same expression always evaluates to the same result, no matter how often we evaluate it. This property makes it easy to design, and to reason about, programs. To cope with interfaces between programs and the rest of the world, however, we enrich the language with assignment statements and abandon some of our algebraic reasoning. The last two parts show what this means for the design of programs. More precisely, they show how the design recipes of the first six parts apply and why we must be much more careful once assignments are added. Intermezzos introduce topics that are important for computing and programming in general but not for program design <#117#>per se<#117#>. Some introduce the syntax and semantics of our chosen subsets of Scheme on a rigorous basis, a few introduce additional programming constructs. Intermezzo~5 is a discussion of the abstract cost of computing (time, space, energy) and introduces vectors. Intermezzo~6 contrasts two ways of representing numbers and processing them. The coverage of some intermezzos can be delayed until a specific need arises. Especially the intermezzos on Scheme's syntax and semantics fall into this category. But, considering the central role of intermezzo~3 in figure~#figdependence#118>, it should be covered in a timely fashion. 4=<#144#>~Part VIII~<#144#>=4 4=<#145#>~Interme 9~<#145#>=4
rawhtml3 <#148#>Figure: The dependencies among parts and intermezzos<#148#>

<#150#>ITERATIVE REFINEMENT AND ITERATION OF TOPICS<#150#>: Systematic program design is particularly interesting and important for large projects. The step from small single-function problems to small multi-function projects requires an additional design idea: iterative refinement. The goal is to design the core of a program and to add functionality to this core until the entire set of requirements is met. Students in a first course can, and must, get their first taste of iterative refinement. Hence, in order to acquaint students with the technique, we have included extended exercises. Typically, a brief overview sets the stage for a collection of exercises. The exercises gently guide students through some design iterations. In section~#secfiles#151>, the idea is spelled out explicitly. Furthermore, the book revisits certain exercise and example topics time and again. For example, sections~#secmovecircle#152>, #secmoveshape#153>, #secmovefig#154>, #secabsmoving#155>, #secmovefinal#156>, and a few exercises in between the last two sections cover the idea of moving pictures across a canvas. The students thus see the same problem several times, each time with more and more knowledge about how to organize programs. Adding pieces of functionality to a program demonstrates why programmers must follow a design discipline. Solving the problem again shows students how to choose from alternative design recipes. Finally, on occasion, new knowledge just helps students improve the program organziation; in other words, students learn that programs aren't finished after they work for the first time but that, like papers and books, they need editing.

<#157#>TEACHPACKS<#157#>: A second aspect of working on projects is that programmers have to work in teams. In an instructional context, it means that one student's program has to fit precisely to someone else's. To simulate what fitting one's function to someone else's means, we provide DrScheme teachpacks. Roughly speaking, a teachpack simulates a team partner yet avoids the frustration of working with mistakes in a partner's program component. More technically, the projects almost always consist of a <#158#>view<#158#> and a <#159#>model<#159#> program component (in the sense of the model-view software architecture). In a typical setting, students design the model component. The teachpacks provide the view components, often in the form of (grapical) user interfaces. Thus they eliminate the tedious, mindless portions of coding. Furthermore, this particular separation of concerns mimics that of real-world projects. Fitting model components to view components requires students to pay attention to precise specifications of functions. It demonstrates the paramount importance of following a design discipline. It is also a critical skill for programmers and is often underemphasized in beginning courses. In part~#partabstract#160> we show how to construct some simple GUIs and how GUI events trigger the application of model functions. The goal is to explain that constructing GUIs is no mystery, but not to spend a lot of time on a topic that requires mostly rote learning and little computational thinking.

<#161#>SCHEDULE<#161#>: Each university, college, and school has its own needs and must find an appropriate schedule. At Rice University, we cover the entire book plus some additional material. An instructor at a research university should probably keep up a similar pace. At the high school end of the book's test users, the pace is slower. Many of the high schools that tested the book covered the first two parts and selected sections from the next two or three in a semester; some used just the first part to teach algebraic problem solving from a computational perspective; and yet others worked through all of the first six parts in a year.

<#162#>THE BOOK ON THE WEB<#162#>: The book comes in two versions: a paper copy and a freely accessible on-line version at

The Web site also provides additional material, especially extended exercises of the style mentioned above. At this time, the Web page offers exercises on visual simulation of ball games and the management of Web site. More exercises will be added. The on-line version of the book contains three kinds of additional hints. Each is marked with one of the following three icons, the first two also occur in the paper copy:


<#163#>TYPOGRAPHY AND DEFINITIONS<#163#>: For readability, Scheme programs are type-set using a small number of fonts. <#164#>Italic words<#164#> refers to program names and variables. <#165#>Sans Serif<#165#> items are constants and built-in operations. <#166#>Boldface<#166#> words are Scheme keywords. Definitions come in three varieties. There are those terms that concern the principles of programming and computing. The book lists the first occurrence of such terms with <#60295#><#167#>SMALL CAPITAL LETTERS<#167#><#60295#>. Other definitions are of a more fleeting nature; they introduce terms that are important for a section, an example, an exercise or some other small part of the book. The book uses <#168#>slanted letters<#168#> to emphasize such definitions. Finally, the book also defines classes of data. Most data definitions are boxed, and the first occurrence of the defined name is also type-set using <#60296#><#169#>slanted words.<#169#><#60296#>