Related to the idea of "Notional Machines" (§4) I recently realised that what I'm calling "denotational strategies" can be vastly more efficient for learning than "operational strategies". For example, learning recursion via an operational semantics / abstract machine model can make recursion seem very complex. Maintaining the stack and tracing through the control flow is hard. Alternatively one can use structural recursion patterns (think proof by induction) in which case you don't have to think through the control flow. The correctness is guaranteed if the individual cases are correct.
Probably this statement isn't so understandable from the above description. It really needs a blog post of its own.
My guess is that "denotational strategies" (from what I can guess you mean) just move the cognitive load around in other places. That doesn't make them worse, but it depends on which kind of cognitive load the learner best copes with.
Agreed that the lack of evidence makes any of my claims not much more than hot air. It's something I'm interested in rectifying but I'm not sure how to do in our context (professional training and free intro to programming).
I think that's true for anyone who's comfortable with proofs by induction, but most people aren't until well past the point where they'd normally learn to program.
You don't need to understand proof by induction to use these techniques. It's more than I have the energy to explain in a comment here, but the chapter on "Structural Recursion" at http://www.creativescala.org/creative-scala.pdf shows some of my thinking (though it has evolved a bit since that written.)
But more importantly, I can tell you that the design recipe isn't enough. That's why we set out to study the notional machine question (paper cited in another response). We most definitely need it too; what we're trying to figure out is what form of notional machine matches best.
Comments
Related to the idea of "Notional Machines" (§4) I recently realised that what I'm calling "denotational strategies" can be vastly more efficient for learning than "operational strategies". For example, learning recursion via an operational semantics / abstract machine model can make recursion seem very complex. Maintaining the stack and tracing through the control flow is hard. Alternatively one can use structural recursion patterns (think proof by induction) in which case you don't have to think through the control flow. The correctness is guaranteed if the individual cases are correct.
Probably this statement isn't so understandable from the above description. It really needs a blog post of its own.
Maybe. I don't believe any claims about "easier" without reasonable experimental evidence. Even in the realm of operational strategies, there are huge differences; see: http://cs.brown.edu/~sk/Publications/Papers/Published/tfk-ev...
My guess is that "denotational strategies" (from what I can guess you mean) just move the cognitive load around in other places. That doesn't make them worse, but it depends on which kind of cognitive load the learner best copes with.
Agreed that the lack of evidence makes any of my claims not much more than hot air. It's something I'm interested in rectifying but I'm not sure how to do in our context (professional training and free intro to programming).
I think that's true for anyone who's comfortable with proofs by induction, but most people aren't until well past the point where they'd normally learn to program.
You don't need to understand proof by induction to use these techniques. It's more than I have the energy to explain in a comment here, but the chapter on "Structural Recursion" at http://www.creativescala.org/creative-scala.pdf shows some of my thinking (though it has evolved a bit since that written.)
Looks rather like an abbreviated version of the _How to Design Programs_ design recipe to me…
It sure is!
Sure would have been nice to give credit, then…
But more importantly, I can tell you that the design recipe isn't enough. That's why we set out to study the notional machine question (paper cited in another response). We most definitely need it too; what we're trying to figure out is what form of notional machine matches best.
You're absolutely right on giving credit. I've added this: https://github.com/underscoreio/creative-scala/commit/6ecaa4...
And thanks for mentioning the paper. I'll give it a read.