I read this book when I was learning functional programming. Since I started learning fp with Haskell, I couldn't figure out in the beginning how you create any meaningful programs with it. All I had were small toy programming problems from the Haskell book I was reading. This book hand-held me through learning fp and the two things that, for me, helped connect the dots were the Space Invaders type game that you build in one of the chapters of HTDP2 and Scott Wlaschin's Domain Modeling Made Functional by Scott Wlaschin. The Space Invaders game showed me how you can create a bigger program that actually is of moderate complexity by composing little functions together!
However the book is an introductory book, so there is a lot of basic stuff if you already know programming.
The authors has the following to say in the Preface.
PREFACE
Many professions require some form of programming. Accountants program spreadsheets; musicians program synthesizers; authors program word processors; and web designers program style sheets. When we wrote these words for the first edition of the book (1995–2000), readers may have considered them futuristic; by now, programming has become a required skill and numerous outlets—books, on-line courses, K-12 curricula—cater to this need, always with the goal of enhancing people’s job prospects.
The typical course on programming teaches a “tinker until it works” approach. When it works, students exclaim “It works!” and move on. Sadly, this phrase is also the shortest lie in computing, and it has cost many people many hours of their lives. In contrast, this book focuses on habits of good programming, addressing both professional and vocational programmers.
By “good programming,” we mean an approach to the creation of software that relies on systematic thought, planning, and understanding from the very beginning, at every stage, and for every step. To emphasize the point, we speak of systematic program design and systematically designed programs. Critically, the latter articulates the rationale of the desired functionality. Good programming also satisfies an aesthetic sense of accomplishment; the elegance of a good program is comparable to time-tested poems or the black-and-white photographs of a bygone era. In short, programming differs from good programming like crayon sketches in a diner from oil paintings in a museum.
No, this book won’t turn anyone into a master painter. But, we would not have spent fifteen years writing this edition if we didn’t believe that
everyone can design programs and everyone can experience the satisfaction that comes with creative design.
Indeed, we go even further and argue that program design—but not programming—deserves the same role in a liberal-arts education as mathematics and language skills.
A student of design who never touches a program again will still pick up universally useful problem-solving skills, experience a deeply creative activity, and learn to appreciate a new form of aesthetic. The rest of this preface explains in detail what we mean with “systematic design,” who benefits in what manner, and how we go about teaching it all.
