I am working through HtDP now. I was initially watching Gregor Kiczales' accompanying playlists[0] on YouTube concurrent with the material. They were good and short enough that I charged through and finished them before reaching the corresponding material in the book.

I think the biggest win is that it's the first source I've found that incrementally teaches a pragmatic understanding of recursion[1]. But also why it works, with the structure of the code following the structure of the data definitions and downward. The videos classify natural, mutual, structural, and generative recursions and explain the who/why/what/etc of each. Gregor's video explanations were great, and the book similarly seems to anticipate many questions I have while working through the problems. At times, parts have been slow, probably due to some prior knowledge[2], but definitely worth the trek.

The first time I learned recursion was basically a "now draw the rest of the owl" trope. I was hoping for so much more in way of explanation and have always felt incapable whenever struggling to approach and solve recursive problems. And questions always just led to non-didactic Inception movie references.

I used to think maybe I was just bad at that type of problem. And maybe I am, but more and more, it feels like people generally - including those teaching - don't actually know the concepts here themselves. It's like the world has just collectively memorized a few examples and refuses to acknowledge the giant spaces between them.

In that sense HtDP has been incredibly refreshing.

[0] https://www.youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w They are the videos that go with the edx course mentioned elsewhere here.

[1] Although I've heard The [Little|Reasoned|etc.] [Schemer|Lisper] books may do similarly.

[2] I'm in my last semester of a CS degree and I have work experience programming

I liked it. My least favorite part wasn't the book itself but rather DrRacket. DrRacket's not bad, in fact it has some slick features, but I don't consider it great either. As an IDE it's good, but as a text editor it's poor. But then again my brain has been poisoned by Vim, DrRacket is probably great for young students without preexisting biases like mine.

I've been using racket for almost all of my recreational programming for the past few years but I don't do it with DrRacket.

I worked through it some years ago because I was interested in Racket. It is solid when it comes to programming, but if your goal is to get the Scheme feeling, the little Schemer would be a much better choice.

BTW a very nice introduction to Racket is also "Realm of Racket".

The book is great, I've been working through HTDP and it's generous amount of programming exercises casually over the past year as a self learner. I had been dabbling in programming over the past several years (as a true dilettante) and have utilized several resources on my journey (CS50, Programming: Principles and Practice Using C++, a touch of SICP), but it wasn't until progressing through HTDP that I really felt confident I was learning HOW to program. The pedagogy the book uses instruct a beginner on how to program is sound and uses many of the concepts touched upon by the popular "Learning How to Learn" edX course. The natural progression of the exercises as well as the evolution of the language used throughout the book(BSL or Basic Student Language) pair nicely and you slowly feel yourself becoming "wizardly" as the training wheels are slowly being stripped away.

The authors do a good great job in promoting good software craftsmanship from the very beginning of the text. Like any good teachers they reinforce the importance of developing good habits that as a beginner you sometimes take for granted, such as writing unit tests for newly defined functions. Thinking through programming exercises is done methodically with HTDPs Design Recipe, which enforces the use a function signature, purpose statement (comments), a header, and functional examples - followed by a template to flesh out the basic structure of the code you will be using to define your function.

I've watched most of the SICP lectures by Sussman and Abelson and while brilliant, it becomes quite clear that even the professional programmers in the room have trouble keeping up with the pace of the lectures. As a beginner, I was acutely aware that I had bitten off more than I could chew and I will revisit them and SICP after completion of HTDP.

As a side note, I discovered small typo in one of the examples and emailed the lead author (Matthias Felleisen) and he responded to me same day very appreciative that I took the time to do so. If he or any of the other authors read this, thank you! I'm still diligently making my way through and enjoying your text!

Only worked through a part of it, but left a pretty good impression. Writing style was pleasant to read, sometimes imagined it read in Bob Ross' voice. Only Scratch has a shorter "zero to moving pictures" time. The language manual is so tightly integrated with the book it doesn't leave a single character of code unexplained (I've read beginner's books that never explained "+=" while using it in code samples). My only nitpick is that the design recipe wasn't sufficiently explained and it finally clicked when I tried the edx course based on the first part of HtDP, which has its own problems like a plodding pace and unchallenging excercises. All in all a great beginner's book.

It's the best book I've found for actually teaching people how to solve problems using programming, rather than just learning semantics.

I use it for continuing education at a company, the only complaint I've heard from people is that it's very deliberately paced.

I do wish there was an equivalent that used a statically typed language, because the actual approach is very fundamentally based on types. I've spoken with the authors about this, and the reasoning was twofold: 1. people are going to have to deal with unityped languages in industry; 2. existing error messages for static languages were bad. At this point, something like Elm might be a good fit, although you'd lose out on lispy things like quasiquote.

1) it's near paradigm agnostic

2) it does not lie, gives a very nice structured way to think about data and processing it through simple cases (product and sum types without naming them)

3) it's quite small step read, nothing as extraordinary as SICP