On HtDP
felleisen.org
On HtDP
1–10 of 36 posts
Re: On HtDP
#2This looks super interesting!
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.
Re: On HtDP
#3Wow, 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.
Re: On HtDP
#4404 for the article linked from the sidebar titled “*SL, Not Racket”
Re: On HtDP
#5Wow, 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.
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.)
Re: On HtDP
#6If 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.
I think https://cs.brown.edu/~sk/Publications/Papers/Published/fffk-... is probably a better overview, though it's quite old now. I'm not aware of any followups. The paper even has its own wikipedia page! https://en.wikipedia.org/wiki/The_Structure_and_Interpretati...
Re: On HtDP
#7Wow, 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.
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.
Re: On HtDP
#8404 for the article linked from the sidebar titled “*SL, Not Racket”
Re: On HtDP
#9404 for the article linked from the sidebar titled “*SL, Not Racket”
You can find it here http://www.ccs.neu.edu/home/matthias/OnHtDP/_SL__Not_Racket....
Re: On HtDP
#10Wow, 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.