How to respond when students ask "is recursion good practice"? Context: CS1-style, intro programming class, using an interpreted language (Python).

I will get a hand raised asking "Why are we learning recursion? Is it good programming practice?"

My response is typically:


We are learning recursion since reducing problems into smaller problems is a key skill, and recursion is just an example of reducing a problem to a self-similar smaller problem.
Also, no, recursion not universally better design. Often, calling functions repeatedly like this wastes space on the stack and the implementation can be much less efficient. Our recursive formulation of factorial for example, is a terrible design. Unless you know the recursion depth is bound by something small (think: logarithmic) and resultant implementation is much simpler, then its not worth it.


Students seem deflated with that response. Why learn something that is not very practical, or is often inefficient? Why learn something that is 'sometimes simpler' when (to them) it seems actually like a counter-intuitive design?

My question(s): how do I get students excited about recursion? How do I better motivate studying recursion? Can I better / more naturally express those conditions under which (or those languages for which) recursion is not a poor design choice?

This is challenging once you accept that CS1 students likely: know nothing about functional languages, where recursion is more natural; don't know anything about side-effect free design or mathematical proofs of correctness; are not using recursive data structures yet; etc. It feels like the 'benefits' of recursion are hard to express to a CS0/CS1 audience.
Quite honestly, I would be upfront with them about the debate. Send them to a couple other SE threads:


Efficiency: recursion vs loop
“Necessary” Uses of Recursion in Imperative Languages
Are functional languages better at recursion?


This now becomes a teachable moment on a number of levels: imperative v. functional languages, recursion v. iteration, "expense" of function calls on the stack. Students appreciate being shown the messy truth behind topics that are sometimes treated reductively and simplistically. Let them wade in the mire and see what they think about these debates. Have them analyze the arguments they mind on here; now they are thinking on much higher, more sophisticated level about program design.

The key line that I take away from all of these is this one: "You almost never use recursion for performance reasons. you use recursion to make the problem more simple" (top answer to the first post I linked to). It's often times an exercise in thinking more so than programming.

From a pragmatic perspective, discuss use cases for something like merge sort and quicksort (recursive) v. bubble sort (iterative). Throw in traversing tree structures as well. There is a time and a place for thinking recursively. Iteration is not always the best choice to make.

Last, from an aesthetic perspective, based on my time studying SML, there is a beauty, an elegance, an aesthetic to a well-written recursive function. It's clean, clear, easy-to-understand. If part of code quality is its readability, then recursion has an aesthetic quality to it that a for-loop arguably does not.