How to Design Programs, second edition(htdp.org)
htdp.org
How to Design Programs, second edition
http://www.htdp.org/
5 comments
What I also like about this book is that it manages to get to "exciting" programs fairly quickly. Like, for a first time programmer, it can be boring to spend all your time writing things that convert Fahrenheit to Celsius or print staircases out of asterisks with double for loops. In this book, it's very easy to work with images, allowing things to move towards things like basic game development very quickly.
Although I like HtDP as a scheme book, I have to say that its title has always been a bit misleading. It certainly doesn't teach you how to design programs, it is rather a good introduction to common scheme programming techniques.
It teaches abstraction and techniques like streams and recursion. In that respect HtPD is very similar to Winston & Horn's Lisp.
It teaches abstraction and techniques like streams and recursion. In that respect HtPD is very similar to Winston & Horn's Lisp.
I teach using HtDP, so my opinions are unsurprising here, but this is very wrong. The central ideas in the book are about data-driven design, specifications, systematic design of correct programs, and abstraction of all kinds. These are fundamental program design techniques, not details of scheme programming.
Been a while since I took the intro CS course from Matthias at Rice (late 90s), but I do remember he was an eloquent teacher who really illuminated for me the idea that you could simplify the design of complex programs through formal techniques (as opposed to the cowboy coding I had picked up in high school). Whether or not I was always disciplined going forward, I've often felt the nudge to take a deep breath and think a bit more because of the image of Matthias speaking so emphatically about these things in my mind.
To see it done with imperative style, check out Stavely's write-up or book on the Cleanroom method:
http://infohost.nmt.edu/~al/cseet-paper.html
I'd like to see a HtDP/Racket attempt at Cleanroom to see what differences or similarities there would be. SPARK Ada and miniKanren, too. It's already closer to them with its algebraic style of specification of programs that use only a few primitives for easier analysis. Edit to add that what DonaldPShimoda describes is exactly what Cleanroom required with its "intended functions."
http://infohost.nmt.edu/~al/cseet-paper.html
I'd like to see a HtDP/Racket attempt at Cleanroom to see what differences or similarities there would be. SPARK Ada and miniKanren, too. It's already closer to them with its algebraic style of specification of programs that use only a few primitives for easier analysis. Edit to add that what DonaldPShimoda describes is exactly what Cleanroom required with its "intended functions."
Had a look at the article you linked to, thanks for sharing.
I've done some work (in projects, not academia) on trying to create low-defect software - by informal methods, not formal verification, so the paper was interesting.
I've done some work (in projects, not academia) on trying to create low-defect software - by informal methods, not formal verification, so the paper was interesting.
Matthew Flatt (at Utah, advisee of Matthias) teaches the same way. He emphasizes test-driven development and formal methods for designing a program that will work.
One of my favorite tricks I picked up was to write the header comment for a function before writing any of the code. Once you've written down what the function is meant to do, it's often almost trivial to actually implement. (This is especially helpful when first learning recursion, as I was when I took the class.)
One of my favorite tricks I picked up was to write the header comment for a function before writing any of the code. Once you've written down what the function is meant to do, it's often almost trivial to actually implement. (This is especially helpful when first learning recursion, as I was when I took the class.)
On this topic, one of my eye-openers was Game Programming Patterns: http://www.gameprogrammingpatterns.com
It’s classic software architecture patterns, only seen through the lens of performance and design iteration speed, which is the way I see the world even though I don’t make what most people would consider games.
It’s classic software architecture patterns, only seen through the lens of performance and design iteration speed, which is the way I see the world even though I don’t make what most people would consider games.
I’ve commented at length about this book before; really, just don’t bother. It’s not very good at patterns, not comprehensive, not clear on how to use them for games or why you might want to use them at all.
Google search “design pattern book”. Right, now take any of those books.
If you want game related stuff try “game programming gems”.
This book is free... that’s literally all it has going for it. Wikipedia has better stuff that you know... actually compiles, etc.
If you got any value out of Game Programming Patterns, I cannot strongly enough recommend you go and read an actually good book on design patterns; you’ve probably been mislead by its vague hand waving and incoherent discussion of the various topics.
Google search “design pattern book”. Right, now take any of those books.
If you want game related stuff try “game programming gems”.
This book is free... that’s literally all it has going for it. Wikipedia has better stuff that you know... actually compiles, etc.
If you got any value out of Game Programming Patterns, I cannot strongly enough recommend you go and read an actually good book on design patterns; you’ve probably been mislead by its vague hand waving and incoherent discussion of the various topics.
I completely disagree. I felt it was a modern followup to the classic Design Patterns (Gang of Four) book. The author is not trying to teach game programming as much as he is demonstrating how they are practical in his line of work.
After seeing the original debate I'm sure I won't add anything you haven't heard already: Game Programming Patterns - https://news.ycombinator.com/item?id=14475489.
nope.
...but once again I recommend anyone who reads this post go browse wikipedia’s design patterns section. Its pretty neat:
https://en.m.wikipedia.org/wiki/Software_design_pattern
...but once again I recommend anyone who reads this post go browse wikipedia’s design patterns section. Its pretty neat:
https://en.m.wikipedia.org/wiki/Software_design_pattern
> I felt it was a modern followup to the classic Design Patterns...
If you’re going to recommend a book, then why not just recommend Design Patterns?
That’s actually a good book; and, if you read it, you will extract exactly zero value from this one, which gives only the most trivial coverage of a handful of the patterns from the former.
/shrug
I feel like people who 5 star review this on amazon didn’t read Design Patterns becuase it looked to scary, and liked it because this was cute and simple and easy.
...unfortunately, the reality is that cute simple explanations are usually trivialising the content (as this book does; seriously go read a few game programming gems if you think game programming is as trivial as a singleton...), so given a choice of a universally acclaimed coverage of the topic, and some hand drawn pictures, why the heck would you recommend the latter to anyone other than a student?
I don’t get it, and I see no value in the content of this book ...but, I guess different things for different people.
If you’re going to recommend a book, then why not just recommend Design Patterns?
That’s actually a good book; and, if you read it, you will extract exactly zero value from this one, which gives only the most trivial coverage of a handful of the patterns from the former.
/shrug
I feel like people who 5 star review this on amazon didn’t read Design Patterns becuase it looked to scary, and liked it because this was cute and simple and easy.
...unfortunately, the reality is that cute simple explanations are usually trivialising the content (as this book does; seriously go read a few game programming gems if you think game programming is as trivial as a singleton...), so given a choice of a universally acclaimed coverage of the topic, and some hand drawn pictures, why the heck would you recommend the latter to anyone other than a student?
I don’t get it, and I see no value in the content of this book ...but, I guess different things for different people.
seems like an interesting addition to SICP. Anyone here who already worked through it?
Back in 2013, when Coursera was free, Gregor Kickzales taught Introduction to Systematic Program Design. It was based on the principles in HtDP. The videos can be found on his YouTube channel: https://www.youtube.com/user/gregorkiczales/videos That class has since morphed onto Edx. It is now part of the Edx Software Development "micro-masters". https://www.edx.org/micromasters/software-development The origin of all those courses is Kickzales' teaching at University of British Columbia...and the PLT Group centered at Boston University.
In comparison to SICP, HtDP is slower paced and more basic in terms of Computer Science. Not surprising since the intended audience of SICP was MIT undergrads rather than those more toward the middle of the high school academic Bell Curve. The other major difference is that HtDP is a specific methodology utilizing specifications, tests, stubs, and other techniques for writing programs.
In terms of Books as Books, SICP is better written. It has far better type-setting and binding. It is a pleasure to read. And to hold. HtDP has a poor physical format and below average typesetting for a textbook, it's just ugly and awkward all around. HtDP doesn't reflect a Knuthian concern with typesetting and the experience is closer to a bound website than TAoCP. =
In comparison to SICP, HtDP is slower paced and more basic in terms of Computer Science. Not surprising since the intended audience of SICP was MIT undergrads rather than those more toward the middle of the high school academic Bell Curve. The other major difference is that HtDP is a specific methodology utilizing specifications, tests, stubs, and other techniques for writing programs.
In terms of Books as Books, SICP is better written. It has far better type-setting and binding. It is a pleasure to read. And to hold. HtDP has a poor physical format and below average typesetting for a textbook, it's just ugly and awkward all around. HtDP doesn't reflect a Knuthian concern with typesetting and the experience is closer to a bound website than TAoCP. =
Just to note, while the classes are part of a paid program at EdX, you can enroll in the individual classes for free. I went through the first one a few years ago and really enjoyed it.
https://www.edx.org/course/how-code-simple-data-ubcx-htc1x
https://www.edx.org/course/how-code-simple-data-ubcx-htc1x
Are you thinking of the print edition? Both books are typeset using TeX, and both are printed by MIT press, so this is a pretty surprising claim.
By "books as books," yes, I mean the print editions. The first edition of HtDP specifically since that is the one I own. By "typesetting" I mean the entire process of producing a physical artifact from an edited manuscript. Thus, I am including aesthetic considerations such as typography, cover design, and binding.
TeX is a technology. In the context of my literary criticism, citing TeX and MIT press is analogous to "styled with CSS and hosted on GoDaddy" in regards to a website. TeX is a tool. MIT Press is a good publishing house and its catalog contains quality, but some of its books are still better than others in terms of typesetting (in the sense described). The differences can reflect authors' goals; publishing economics; and just the times (HtDP came about in the era of the commercial web).
Personally, I find the unconventional physical format of HtDP (8" x 9") awkward. It's unbalanced. The pages are too wide. The compensating increase in font size makes the lines so tall that there is low information density on each page. As a reader, the amount of head/eye movement for a disrupts my concentration. The gutters are far too wide. I suppose that the wide gutters were to accommodate the Lambda icon, but these peter out in the first quarter of the book. Because these could be taken away with little effect their inclusion is a decision that could have been revisited and a more conventional layout considered.
The typography is haphazard. Code on page 191 uses san-serif. Code on page 322 is set in four faces; a mix of serif and san-serif, bold, and italics; and boxes. Page 299 has its own notation. Often its complexity obscures the big ideas: on page 278 the unimportant ideas are in bold (local is irrelevant to the local point of f's referent) [1] and the diagram's arrows connect the thinnest term and the thinnest term is typeset in italic.
Please don't take my remarks personally except in so far as I think HtDP is a book worth owning and reading and that the world is better for it existing in its current form. It's useful and supports an important project that I like. Thanks.
[1] Page 279 uses nested boxes to express locality. These have semantics distinct from boxes on page 322.
TeX is a technology. In the context of my literary criticism, citing TeX and MIT press is analogous to "styled with CSS and hosted on GoDaddy" in regards to a website. TeX is a tool. MIT Press is a good publishing house and its catalog contains quality, but some of its books are still better than others in terms of typesetting (in the sense described). The differences can reflect authors' goals; publishing economics; and just the times (HtDP came about in the era of the commercial web).
Personally, I find the unconventional physical format of HtDP (8" x 9") awkward. It's unbalanced. The pages are too wide. The compensating increase in font size makes the lines so tall that there is low information density on each page. As a reader, the amount of head/eye movement for a disrupts my concentration. The gutters are far too wide. I suppose that the wide gutters were to accommodate the Lambda icon, but these peter out in the first quarter of the book. Because these could be taken away with little effect their inclusion is a decision that could have been revisited and a more conventional layout considered.
The typography is haphazard. Code on page 191 uses san-serif. Code on page 322 is set in four faces; a mix of serif and san-serif, bold, and italics; and boxes. Page 299 has its own notation. Often its complexity obscures the big ideas: on page 278 the unimportant ideas are in bold (local is irrelevant to the local point of f's referent) [1] and the diagram's arrows connect the thinnest term and the thinnest term is typeset in italic.
Please don't take my remarks personally except in so far as I think HtDP is a book worth owning and reading and that the world is better for it existing in its current form. It's useful and supports an important project that I like. Thanks.
[1] Page 279 uses nested boxes to express locality. These have semantics distinct from boxes on page 322.
I'm not the person you're replying to, but that's not really pretty surprising. Merely typesetting a book in TeX does not guarantee good typesetting. TeX is just a program that makes it possible to typeset like “real books”; one still needs to know (and care) enough about book design (as Knuth did) to actually produce something aesthetically pleasing. (For an extreme example: if you just run TeX and don't pay attention to the warnings, you'll have plenty of underfull or even overfull lines, resulting in even worse typesetting than you'd get from something like Microsoft Word.) The standard LaTeX classes also make some poor typographic choices, because Lamport unlike Knuth was more interested in logical/structured markup than typesetting.
Nor does being published by a reputed publisher guarantee good typesetting. The story of TeX is itself a good example: TeX came into existence because Addison-Wesley, whom Knuth had chosen specifically for their great typesetting, was compromising on their typesetting for the 2nd edition of TAOCP vol 2 as they moved away from hot-metal typesetting. I'd expect that things are even worse today.
In the case of HtDP specifically, just opening the print edition of the book and flipping through the pages, I can see how its typesetting is indeed below average for a textbook. Look at the ugly table on page 21 (and throughout the book), the uneven typographic “color” on pages like 23 and 31, and just the whole mishmash of mismatched fonts on most pages. The book also has a lot of short paragraphs (two or three lines long), so the choice of indentation for paragraphs in the book is an odd one. A good book designer would have changed a lot of this.
Overall it's perfectly readable, and sure, all typographic subtleties fade away once a reader gets sufficiently engrossed in the content (which is what ultimately matters), but the book is not a delight to hold in one's hands even before that, as in the case of TAOCP. (Probably unfair to compare with something well above average (TAOCP), so compare with SICP which is probably at about the average for a textbook from MIT Press.)
Nor does being published by a reputed publisher guarantee good typesetting. The story of TeX is itself a good example: TeX came into existence because Addison-Wesley, whom Knuth had chosen specifically for their great typesetting, was compromising on their typesetting for the 2nd edition of TAOCP vol 2 as they moved away from hot-metal typesetting. I'd expect that things are even worse today.
In the case of HtDP specifically, just opening the print edition of the book and flipping through the pages, I can see how its typesetting is indeed below average for a textbook. Look at the ugly table on page 21 (and throughout the book), the uneven typographic “color” on pages like 23 and 31, and just the whole mishmash of mismatched fonts on most pages. The book also has a lot of short paragraphs (two or three lines long), so the choice of indentation for paragraphs in the book is an odd one. A good book designer would have changed a lot of this.
Overall it's perfectly readable, and sure, all typographic subtleties fade away once a reader gets sufficiently engrossed in the content (which is what ultimately matters), but the book is not a delight to hold in one's hands even before that, as in the case of TAOCP. (Probably unfair to compare with something well above average (TAOCP), so compare with SICP which is probably at about the average for a textbook from MIT Press.)
Haven't read this book yet, but it was designed to be a more accessible and practical alternative to SICP. Check the authors' paper comparing the two (pdf) [1].
Taking a look at the contents, once a person has read through SICP and understood it, they may find most of HtDP to be boring. It would be much better to read HtDP before SICP than the other way around.
[1] https://cs.brown.edu/~sk/Publications/Papers/Published/fffk-...
Taking a look at the contents, once a person has read through SICP and understood it, they may find most of HtDP to be boring. It would be much better to read HtDP before SICP than the other way around.
[1] https://cs.brown.edu/~sk/Publications/Papers/Published/fffk-...
It was the book that was used in my first programming class in college (Northeastern). One of the authors, Matthias, was part of the course staff. It's definitely interesting as it differs from most non-functional programming intro course books and sets up a more rigorous foundation for students to use when they go on to learn about class based design with Java in the second semester.
I guess it might be a bit strange to think that we don't encounter iteration until the latter part of our second semester but it does make student get really familiar with recursion.
Not sure how I would have handled it if I had to work through it alone but I would at least recommend people to give the book a look.
I guess it might be a bit strange to think that we don't encounter iteration until the latter part of our second semester but it does make student get really familiar with recursion.
Not sure how I would have handled it if I had to work through it alone but I would at least recommend people to give the book a look.
Similar situation here... one of the core Racket dev team members (i.e. PLT) works here, and we use HtDP in our one-semester Intro to CS (211) class. They specifically advertise it to those who have little to no past programming experience, with the only prereq being high school precalc; it's pretty rigorous and definitely covers a lot of stuff that my past programming textbooks didn't at all (e.g. recursion out the wazoo, abstraction). Here, it sets up for our 212 class, Intro to Software Systems, which is another semester class, all done in Java and about OOP. Seems like a mildly jarring switch if you ask me.
Even with my past experience, I still needed a ton of help from professors and other students. It's kinda daunting to think about doing it alone, without much help.
Even with my past experience, I still needed a ton of help from professors and other students. It's kinda daunting to think about doing it alone, without much help.
HtDP is a much less difficult warmup often used to prepare students for SICP.
has anyone got a PDF or EPub of this?
https://course.ccs.neu.edu/cs2500/texts.html
Not aware of a PDF, but this version (just click "How to Design Programs") has a UI where you can go to each chapter and subsection with the sidebar. Pretty nifty.
Not aware of a PDF, but this version (just click "How to Design Programs") has a UI where you can go to each chapter and subsection with the sidebar. Pretty nifty.
This was posted on Reddit last week: https://my.mixtape.moe/bnkrpd.epub
Works fine.
Works fine.
Matthew (one of the authors) told me that they aren't allowed to release a PDF, even though they can post the full text as webpages.
I really like this book.