Как проектировать программы, второе издание

© 2004–2013 Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi; comments to: matthias at ccs.neu.edu

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

Заметили наклонный шрифт? Он используется для обозначения технических терминов. В данном случае он означает названия книг, которые вы можете встретить на полках магазинов.

Плохо программировать — легко. Даже Чайник может научиться за 21 день.

Хорошее умение программировать требует вдумчивости, но она доступна любому, также как любой может испытывать удовольствие, которое приходит с ней. Цена полностью оправдана чистым удовольствием процесса открытий, элегантностью результата и коммерческими выгодами процесса систематизированного проектирования программ.

Целью этой книги является знакомство читателей всех возрастов и уровней подготовки с ремеслом систематизированного проектирования программ. Мы предполагаем наличие всего нескольких умений: арифметика, немного школьной алгебры, а также стремление думать и решать проблемы. Мы обещаем, что тяжкий труд окупится не только будущим программистам, но любому, кому необходимо будет следовать процессу или создавать его для других.

Мы благодарны Ada Brunstein, нашему редактору в MIT Press, которая дала нам разрешение разрабатывать вторую редакцию "Как проектировать программы" в онлайне.

Friday, August 30th, 2013

Note: this document is the current release of HtDP/2e. It is updated in conjunction with PLT software releases, roughly in sync with semester spans. It is thus well-suited for courses. In contrast, the current draft changes on a frequent basis; it should be consulted when people discover problems and/or errors in this document. If such flaws exist in both documents, please report them to the first author.

Acknowledgments: We thank Ennas Abdussalam, Saad Bashir, Steven Belknap, Stephen Bloch, Rodolfo Carvalho, Nelson Chiu, Richard Cleis, John Clements, Christopher Felleisen, Sebastian Felleisen, Ryan Golbeck, Josh Grams, Jack Gitelson, Scott Greene, Kyle Gillette, Nadeem Abdul Hamid, Wayne Iba, , Jordan Johnson, Blake Johnson, Gregor Kiczales, Eugene Kohlbecker, Jackson Lawler, Jay McCarthy, Mike McHugh, Wade McReynolds, Ann E. Moskol, Scott Newson, Paul Ojanen, Prof. Robert Ordóñez, Klaus Ostermann, Nick Pleatsikas, Luis Sanjuán, Lisa Scheuing, Willi Schiegel, Vinit Shah, Nick Shelley, Stephen Siegel, Joe Snikeris, Vincent St-Amour, Marc Smith, Dave Smylie, Kevin Sullivan, Yuwang Yin, David Van Horn, Mitchell Wand, Michael Wijaya, Ewan Whittaker-Walker, and Roelof Wobben for comments on previous drafts of this second edition.

Differences: This second edition of “How to Design Programs” continues to present an introduction to systematic program design and problem solving. Here are some important differences:

  1. The recipes are applied in two different, typical settings: interactive graphical programs and so-called “batch” programs. The former mode of interaction is typical for games, the latter for data processing in business centers. Both kinds of programs are still created with our design recipes.

  2. While testing has always been a part of the “How to Design Programs” philosophy, the software 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.

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

  4. The book and its programs employ new libraries, also known as 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.

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

    HtDP/1e

    HtDP/2e

    contract

    signature

    union

    itemization