Donald Knuth has the opposite view: he thinks recursion is more fundamental. Funnily, he uses an example much like yours.
> On the other hand, recursion is quite fundamental. It is not inherently a high-level concept, suitable only for grownups but not for children. Most people actually grew up with an implicit understanding of rudimentary recursion long before they understood iteration—that is, before they understood how to carry out a loop of instructions. Given a list of tasks to do, the simplest mode of operation is a recursive approach that charges blindly ahead: […]
> It's only after we've gained experience with such an almost mindless method that we acquire a more global view of the process:
> Do Jobs = Do each job on the list. (2)
> […]
> Do a_k for 1 ≤ k ≤ n. (5)
> All computer programmers have in fact progressed from stage (1) to these later stages rather early in our lives, because of an inner desire to “see through” the entire chain of consequences that result from primitive actions.
> Furthermore, once we reached these later stages, we entirely forgot that they were actually elaborations of the recursive procedure in (1). There was no point in narrowing our perspective to the simple-minded form. The vast majority of recursive situations that faced us as children fell into very simple patterns that could readily be “seen through” and understood as a unit. Thus we came to understand iteration as an elementary idea.
> It was only later, when faced with difficult problems whose recursive structure cannot be visualized in straightforward terms such as operations on arrays of elements, that we re-learned the importance of recursion. Therefore we now tend to regard recursion as a high-level concept, although it is really fundamental.
Possibly these views of his are influenced by his early background in programming in assembly/machine language, where it takes some sophistication to translate recursive ideas into code (maintaining a stack etc), but it's an interesting point of view worth some consideration. This is from his draft of TAOCP Chapter 8 ("Recursion"), and is preceded by the following paragraph:
> High-level languages for computing—which themselves are de ned recursively, because algebraic formulas are built up from algebraic formulas—allow programmers to pretend that recursion is real, that a computer is somehow manufactured from recursive components. But programs that invoke themselves are actually implemented by means of a stack structure behind the scenes. A good programmer is able to understand such algorithms by viewing them simultaneously at a high level and at the machine level, and at many levels in between, thereby perceiving what a real computer can actually do well.
> On the other hand, recursion is quite fundamental. It is not inherently a high-level concept, suitable only for grownups but not for children. Most people actually grew up with an implicit understanding of rudimentary recursion long before they understood iteration—that is, before they understood how to carry out a loop of instructions. Given a list of tasks to do, the simplest mode of operation is a recursive approach that charges blindly ahead: […]
> It's only after we've gained experience with such an almost mindless method that we acquire a more global view of the process:
> Do Jobs = Do each job on the list. (2)
> […]
> Do a_k for 1 ≤ k ≤ n. (5)
> All computer programmers have in fact progressed from stage (1) to these later stages rather early in our lives, because of an inner desire to “see through” the entire chain of consequences that result from primitive actions.
> Furthermore, once we reached these later stages, we entirely forgot that they were actually elaborations of the recursive procedure in (1). There was no point in narrowing our perspective to the simple-minded form. The vast majority of recursive situations that faced us as children fell into very simple patterns that could readily be “seen through” and understood as a unit. Thus we came to understand iteration as an elementary idea.
> It was only later, when faced with difficult problems whose recursive structure cannot be visualized in straightforward terms such as operations on arrays of elements, that we re-learned the importance of recursion. Therefore we now tend to regard recursion as a high-level concept, although it is really fundamental.
Possibly these views of his are influenced by his early background in programming in assembly/machine language, where it takes some sophistication to translate recursive ideas into code (maintaining a stack etc), but it's an interesting point of view worth some consideration. This is from his draft of TAOCP Chapter 8 ("Recursion"), and is preceded by the following paragraph:
> High-level languages for computing—which themselves are de ned recursively, because algebraic formulas are built up from algebraic formulas—allow programmers to pretend that recursion is real, that a computer is somehow manufactured from recursive components. But programs that invoke themselves are actually implemented by means of a stack structure behind the scenes. A good programmer is able to understand such algorithms by viewing them simultaneously at a high level and at the machine level, and at many levels in between, thereby perceiving what a real computer can actually do well.