3 ms·
I think this depends on whether you're teaching down or up. I suspect both work for different people. (Down == "here's some abstract concept, here's some code
by FeepingCreature 10y ago
I think this depends on whether you're teaching down or up. I suspect both work for different people.
(Down == "here's some abstract concept, here's some code that implements it in the language's abstract model", Up == "Okay so everytime you call a function, a new stackframe is created." That's the approach I personally prefer.)
I think the reason why recursion is so hard to understand is that programming languages are incredibly misleading. You see "int a = 5;" and you assume that there's a unique 'a' to which 5 has just been assigned, which is of course a complete lie; 'a' is a template for a memory location which is defined only when the function is called. If you don't know this, recursion makes zero sense. "What, now there's two a's??"
I should go do a blogpost on this.
- noelwelsh 10y agoI think trying to reason about recursion in terms of stack frames is madness. I find it quickly overwhelms my working memory. This is why we have the patterns---so you don't have to reason on the machine level. It's similar[1] to proof by induction, on the off chance that helps. [1] By similar I mean exactly the same as.
- FeepingCreature 10y agoI think reasoning about recursion in terms of stackframes is silly. But stackframes are useful for getting a handle on how recursion functions at all.
- noelwelsh 10y agoAh, I see. Agreed with that.
- qwertyuiop924 10y agoWell, no. Reasoning about stackframes, or even about recursive calls at a higher level, is how I understand a lot about recursion. It's also the only way to reason about whether a function will build up stack frames.