On HtDP

The UBC course on edX, now called HtC (How to Code), closely follows this second edition

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.

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.

noelwelsh's suggestions (and book) are good as well, seconding those.

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.

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.