Today I got to the point in my course when I was finally able to teach my students why you see a big lambda every time you start up DrScheme. As I was explaining it, something clicked for me about why the HTDP curriculum works. As has been said many times before, it's not syntax-based, which is definitely good — you don't want your students thinking that they need a new piece of syntax for every problem or that the kinds of syntax available in language X are somehow a mirror of the kinds of problems in computing. But what's not so obvious is that once you're teaching, you start to realize that it's actually small-step semantics-based. Unlike SICP, which doesn't seem to have much of a unifying pedagogical principle, I've started to realize more and more that the secret weapon of HTDP is that you teach the students a simple algebraic-simplification-based view of program evaluation, and then slowly enrich the set of reduction rules in the language and show them what tricks are possible with those new reductions. That's why the introduction of local (a teaching form for introducing internal definitions) becomes a big deal in HTDP, whereas introducing lambda is not all that big of a deal — local is a new kind of reduction rule that adds definitions to the world; lambda on the other hand just follows the same rules we've been using all along.
That's not to say that students don't still need to practice and struggle with both local and lambda to figure out how they tick; that's more of a pragmatics issue. But as far as explaining them, when you get to lambda, you just say, "Remember our rule for how to simplify named functions? You do that here too." Then you do an example or two, and pretty soon people are able to feed you the right answers when you ask what to do next and they've got their first handholds on a concept that might otherwise be very very difficult to grasp.
I have appreciated the pragmatics of HTDP, in particular the design-recipe idea, for a long time, and I still have to say that the notion that data leads directly to code is a fantastic first lesson in programming that's underappreciated in most curricula and by many professional programmers. But I hadn't until just today appreciated the powerful impact that taking a very careful look at the semantic model you're teaching your students when you introduce them to programming can have.
That's not to say that students don't still need to practice and struggle with both local and lambda to figure out how they tick; that's more of a pragmatics issue. But as far as explaining them, when you get to lambda, you just say, "Remember our rule for how to simplify named functions? You do that here too." Then you do an example or two, and pretty soon people are able to feed you the right answers when you ask what to do next and they've got their first handholds on a concept that might otherwise be very very difficult to grasp.
I have appreciated the pragmatics of HTDP, in particular the design-recipe idea, for a long time, and I still have to say that the notion that data leads directly to code is a fantastic first lesson in programming that's underappreciated in most curricula and by many professional programmers. But I hadn't until just today appreciated the powerful impact that taking a very careful look at the semantic model you're teaching your students when you introduce them to programming can have.
0 Comments:
Post a Comment
<< Home