On this page:
How to Design Programs, Second Edition
6.1.0.8

How to Design Programs, Second Edition

© 1 August 2014 MIT Press

This material is copyrighted and provided under the Creative Commons CC BY-NC-ND license [interpretation].

Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi

Do you notice the italics? Italicized words refer to technical terms. Here they refer to books on programming currently in bookstores.

Bad programming is easy. Even Dummies can learn it in 21 days.

Good programming requires thought, but everyone can do it and everyone can experience the extreme satisfaction that comes with it. The price is worth paying for the sheer joy of the discovery process, the elegance of the result, and the commercial benefits of a systematic program design process.

The goal of our book is to introduce readers of all ages and backgrounds to the craft of designing programs systematically. We assume few prerequisites: arithmetic, a tiny bit of middle school algebra, and the willingness to think through issues. We promise that the travails will pay off not just for future programmers but for anyone who has to follow a process or create one for others.

Draft Release

This document is the draft release of HtDP/2e. It is updated on a frequent basis. The stable version is released in conjunction with the PLT software and is thus more suitable for teaching than this draft.

Released on Sunday, September 28th, 2014 6:50:41pm

How the Second Edition Differs from the First

This second edition of “How to Design Programs” differs from the first one in several aspects:

  1. The second edition explicitly acknowledges the difference between designing a program and designing a bunch of functions. In particular, this edition focuses on two kinds of programs: interactive, reactive (graphical) programs and so-called batch programs.Because graphical interactive programs are more interesting than batch programs, the book emphasizes the former over the latter.

  2. The design of a program proceeds in a top-down planning and a bottom-up construction fashion. We explicitly show how the interface to the libraries dictates the shape of certain program elements. In particular, the very first phase of a program design yields a wish list of functions. While the concept of a wish list existed in the first edition, the second edition treats it as an explicit design element.

  3. The design of each wish on the wish list exploits the design recipe for functions. As in the first edition, the six parts focus on structural design, compositional design, generative recursion, and design of both structural and generative programs with accumulators.

  4. A key element of structural design is the definition of functions that compose others. This design-by-compositionWe thank Dr. Kathi Fisler for focusing our attention on this point. is especially useful for the world of batch programs. Like generative recursion, it requires a eureka, specifically a recognition that the creation of intermediate data by one function and processing the intermediate data by a second function simplifies the overall design. Again, this kind of planning also creates a wish list, but formulating these wishes calls for an insightful development of an intermediate data definition. This edition of the book weaves in a number of explicit exercises on design-by-composition.

  5. While testing has always been a part of the “How to Design Programs” philosophy, the teaching languages and DrRacket started supporting it properly only in 2002, just after we had released the first edition. This new edition heavily relies on this testing support now.

  6. This edition of the book drops the design of imperative programs. The old chapters remain available on-line. The material will flow into the second volume of this series, “How to Design Components.”

  7. The book’s examples and exercises employ new teachpacks. The preferred style is to link in these libraries via so-called require specifications, but it is still possible to add teachpacks via a menu in DrRacket.

  8. Finally, we decided to use a slightly different terminology:

    HtDP/1e

    HtDP/2e

    contract

    signature

    union

    itemization

Acknowledgments

The HTML layout is due to Matthew Butternick who created these styles for the Racket documentation.

We thank Ennas Abdussalam, Saad Bashir, Steven Belknap, Stephen Bloch, Elijah Botkin, Anthony Carrico, Rodolfo Carvalho, Estevo Castro, Stephen Chang, Nelson Chiu, Jack Clay, Richard Cleis, John Clements, Mark Engelberg, Christopher Felleisen, Sebastian Felleisen, Adrian German, Jack Gitelson, Kyle Gillette, Scott Greene, Ryan Golbeck, Josh Grams, Nadeem Abdul Hamid, Jeremy Hanlon, Craig Holbrook, Wayne Iba, Jordan Johnson, Blake Johnson, Erwin Junge, Gregor Kiczales, Eugene Kohlbecker, Jackson Lawler, Jay McCarthy, Mike McHugh, Wade McReynolds, Ann E. Moskol, Scott Newson, Paul Ojanen, Prof. Robert Ordóñez, Laurent Orseau, Klaus Ostermann, Sinan Pehlivanoglu, Eric Parker, Nick Pleatsikas, Norman Ramsey, Krishnan Ravikumar, Jacob Rubin, Luis Sanjuán, Lisa Scheuing, Willi Schiegel, Vinit Shah, Nick Shelley, Matthew Singer, Stephen Siegel, Joe Snikeris, Vincent St-Amour, Marc Smith, Dave Smylie, Reed Stevens, Kevin Sullivan, Éric Tanter, Thanos Tsouanas, Yuwang Yin, David Van Horn, Jan Vitek, Mitchell Wand, Michael Wijaya, G. Clifford Williams, Ewan Whittaker-Walker, Julia Wlochowski, and Roelof Wobben for comments on previous drafts of this second edition.

We are grateful to Ada Brunstein, our editor at MIT Press, who gave us permission to develop this second edition of "How to Design Programs" on-line.