Bingo. Recursion is easy in the func^H^H^H^H&quot;application-oriented programming&quot; model of computing where the whole program is a mathematical expression written out in tree form on a blackboard, and applying a function means erasing a node that says (fib 8) and replacing it with a node that says (+ (fib 7) (fib 6)), and eventually with one that says 21. But most programmers, most of the time, seem to use a different mental model, one of functions as little actors that send function-call messages to each other and themselves, including when they are doing &quot;functional programming&quot; (and ofc mutable state and performance considerations tend to push the language into this model anyway). The problem is that in an actors-ish model <i>continuations</i> are easy, while recursion and function-call behaviour in general are hard, derived concepts built on top of continuations.<p>So I&#x27;ve come to think that introductions to programming should usually look something like this:<p>Stage 1: Teach &quot;application-oriented programming&quot;: functional programming that&#x27;s <i>explicitly</i>, and exclusively, about substituting expressions in an expression tree.<p>Stage 2: Teach how to program using <i>only</i> simple &quot;dataflow&quot; models of stateless (or stateful) actors that reliably pass messages (ie. call continuations) to each other in parallel. (To prepare for stage 3 you&#x27;ll need to cover &quot;dynamic dataflow&quot; with actors passing around the capabilities to call other actors, but it&#x27;s also a good opportunity to probe what can reasonably be done with a static graph of calling capabilities.)<p>Stage 3: If the students are led to push the Stage 2 programming models hard enough they&#x27;ll naturally see that a lot of the code they write for those models (but NOT all of it) really wants to be able to take advantage of an explicit function-call abstraction. Teach them how to implement the Stage 1 language as a DSL inside a Stage 2 language.<p>Almost as an incidental benefit the students will end up understanding call&#x2F;cc, too. By contrast, it&#x27;s the attempt to blur these two, very different, models of computing together and handwave the distinction that leaves students confused by recursion—and they <i>should</i> feel confused by recursion in this case! The feeling of confusion is their intellect warning them that something is wrong. The real damage is done when they either give up, or end up feeling that they understand it when they don&#x27;t.<p>(Another side benefit is that it&#x27;s an early introduction to the huge and indispensable diversity, and yet intense inter-relatedness, of models of computing. Among other things that should hopefully temper the zeal to smash square pegs through the One True, Round Hole, and hopefully even the polar opposite vice of unthinkingly picking up whatever &quot;the tool for the job&quot; is supposed to be. Similarly, the order of stage 1 and stage 2 could be reversed.)<p>TL:DR: &quot;Continuations are easy: <i>functions</i> are hard.&quot;<p>PS: The really fun question is how lexical scope fits into the Stage 2 model. It&#x27;s a restricted case of something else...