Just wanted to note that HtDP is the best pedegogy for teaching the foundations of CS that I've ever found.
However, the book really needs professional editing.
Instead, take a look at the Intro CS classes from University of British Columbia [0][1].
They are taught by the excellent Gregor Kiczales, and directly follow the course structure from HtDP, in an extremely learner-friendly way. Absolutely the best online course I've ever done, Gregor really put an enormous amount of effort into doing this right.
I wouldn't say it needs an editor. It is dense! Very dense. I started the book 20 times. I would go from page one till I got stuck and then go back and see what I missed. Took forever to get through it but it was the best thing I have gone through learning anything in computer science.
Are you looking at the first edition or the second? The first is very dense early on. The second was rewritten to avoid that. Take a look at the second edition instead: I'm confident you'll find it qualitatively very different. https://htdp.org/2018-01-06/Book/
I took it when it was on edX and found it much more accessible than the first edition of the book (which I started and never finished when I found the video course).
It's presented by Gregor Kiczales, who gives a compelling introduction here that explains the rationale behind HtDP, and is what lead me to take the course: https://youtu.be/dJbpHukiQ7I (it's fine to start from ~2 minutes onwards).
I still find myself using the process he outlines (defining the purpose of functions up front, describing the data they work on, and giving examples before writing code). I'd describe it as a sort of, “extreme inline readme-driven development[1]”.
If anyone did this course and has since read the second edition of HtDP, I'd love to know what more it adds.
Thank you for adding that — I didn't know the edX courses were still online under a different name! The links from wikibob's comment for those interested:
I took my first Programming Languages course from Matthew Flatt (another of the authors of HtDP) which was taught using PLAI [0] (by Krishnamurthi, another author of HtDP) and HtDP. I know Matthew is pretty passionate about the HtDP style of teaching computer science (and Krishnamurthi is, too), but I had never thought to look more into Felleisen's thoughts on the matter.
If people are interested in understanding the design rationale of HtDP I'm not sure this is the best source. I think you already need a pretty good understanding of HtDP is get the most out of this, though the "Turing is Useless" section is good stuff.
What would one recommend after HtDP (for someone who is a complete beginner)?
As I've just about come to the end of the wonderful course on edx using this book, I have been considering what I should use for the next step.
SICP seems to be a common recommendation however I've read a few comments on the difficulties with math and other things seeing as the book was originally written for MIT students.
Seeing as how highly regarded SICP is should I try it even though I consider myself to be weak at math?
Beyond the courses, it depends on your goals and interest. I would stick with functional programming (FP) to avoid confusion right now, rather than moving to an imperative language. I would first go through PLAI (see http://racket-lang.org/books.html for a link and other Racket books) because I think understanding some programming language theory is super-useful. If you understand PLAI you're well ahead of most programmers IMO, and there is no need to read SICP. Learning a typed language such as Haskell, Scala, or O'Caml might be a useful next step. My own book, Creative Scala, is very much in the HtDP tradition (http://www.creativescala.org/) though it might be a bit basic at this point. Beyond that, whatever takes your fancy.
A quick note on SICP: I don't believe in great books, more the right book at the right time. When I read SICP it was at exactly the right time for me, but I can see with retrospect the presentation is a bit old-fashioned in many ways. If you can work through PLAI you'll have learned most of the big lessons from SICP.
Thank you for taking the time to write such a detailed response. I will absolutely be looking at your recommendation and hold off on SICP until it is the right time.
I agree with Noel about PLAI. It might be an excellent follow-up.
You could also look into the Racket Guide for transitioning to Racket.
If you want to keep working on more complex interactive programs, instead, the lux module (https://docs.racket-lang.org/lux/index.html) might be more efficient than 2htdp/universe. The latter is just amazing, but not intended to be used in contexts where performance may matter, at least in its current implementation.
Since I'm neither an instructor nor a novice, my absolute favorite part of HtDP is the introduction. I like that it makes a case for systematic design as an important object of study, and I like that it proposes a recipe.
If I had to teach computer programming to somebody who was totally new to the subject, HtDP would be my first choice by a mile.
"Our experience shows that a prior understanding of functional style produces significantly stronger programmers than an immediate immersion into the OOP monoculture."
Wow, just read that bit about "HtDP and Colleagues". What a pretentious bit of writing with no actual arguments. The strawman they propose is just one argument, and is not the one I would reach for when arguing against Racket in CS1. I am open to being persuaded about these silly language wars, but the argument there is completely uncompelling. I hope they have the real back-and-forth laid out somewhere else.
> Wow, just read that bit about "HtDP and Colleagues". What a pretentious bit of writing with no actual arguments.
Taking your points in reverse order:
Yes, it doesn't make an argument. It doesn't hold itself out as an argument, but as a narrative relating of personal experience and recommendation of how to address similar experiences. Not every piece of human communication is or needs to be an argument.
Is it pretentious? Maybe; I mean, it clearly engages in what it belatedly admits is a potentially overgeneralization of personal experience, and one could view from overweighting one's own experience as pretentious.
But...whatever. It does, even if it is at the very end, acknowledge the issue.
> The strawman they propose is just one argument, and is not the one I would reach for when arguing against Racket in CS1
Presumably, you are not one of the author’s colleagues at Northeastern; also, Racket is only used in HtDP in the sense that the student languages are themselves implemented in Racket; each is its own distinct Racket/Scheme-like language, but is neither Racket nor Scheme.
Also, it doesn'tt address a single objection to the HtDP pedagogical approach, but several which it views as having a common underlying motivation.
> I am open to being persuaded about these silly language wars
While there are suggestions in the article for dealing with resistance to the HtDP method, those suggestions (and most of the objections they address) are not language wars, or even language-based. If you were open to being persuaded, you would probably at least have read closely enough to recognize that.
> but the argument there is completely uncompelling
There is not even an argument being made; it's advice on how to mollify certain objections, not an argument aimed at rebutting them. The audience isn't people that need to be convinced that HtDP is a good approach, and what it presents also isn't an argument to be used on resistors. It assumes that the audience is not only already convinced, but in also in a position (as the author was during the experience motivating this) where they don't need to convince resistors by argument, but where they are free enough that they can mollify them with accommodations and while proving the value of the mechanism by experience in action.
HtDP is not about the language. It's about the design recipe, which is a structured way to go about programming that is not language specific, and is sometimes used in other languages like Java.
And even Felleisen's HtDP course isn't taught in Racket: it's taught in a sequence of "student languages".
EDIT: Some of this is mentioned on these pages, but not explained very well if you hadn't heard of HtDP. See some of the better links that other commenters have posted.
We know that, thanks. (Co-author of both book and language here.) It doesn't obviate the point that @justinpombrio was trying to make, which is the relevant response to the parent post.
If you wanted to make your comment useful to other readers, describing the argument you would reach for would be a good step. I read the same section and thought it was a reasonable response to an objection I have seen come up (slightly different context---it wasn't HtDP but still a change to the introductory programming course.)
It's amusing that you get so riled up about a page that is not only not about "language wars", it's in fact exactly about taking a multi-lingual perspective _instead_ of getting bogged down in a language war.
By the way, that page is based on discussions correspondents of the HtDP authors have had in dozens of departments. Without that experience, I'm not sure quite how you can even judge what is written there beyond your claim about the writing style (which you are of course welcome to judge independently of any data).
However, the book really needs professional editing.
Instead, take a look at the Intro CS classes from University of British Columbia [0][1].
They are taught by the excellent Gregor Kiczales, and directly follow the course structure from HtDP, in an extremely learner-friendly way. Absolutely the best online course I've ever done, Gregor really put an enormous amount of effort into doing this right.
[0] https://www.edx.org/course/how-code-simple-data-ubcx-htc1x [1] https://www.edx.org/course/how-code-complex-data-ubcx-htc2x