My dog => My friend's dog => My father's friend's dog => My father's sister's cousin's nephew's teacher's friend's plumber's dog's chew toy.

We can construct sentences like this with a completely arbitrary level of recursive nesting. It's so natural that people do it without thinking about it. Recursion only becomes unnatural when we prime people on it and get them thinking it's scary and complicated.

    Darth Helmet: I am your father's brother's nephew's cousin's former roommate.

    Lonestar: What does that make us? 

    Darth Helmet: Absolutely nothing.

It's VASTLY simpler than the alternative. See how difficult it is to express the same relationship without using the recursive grammar.

Anyway, give anyone a family tree diagram containing all of these relationships and they can follow the chain from that sentence to the destination. This is the essence of why we use recursion in computer science in the first place: it's the best tool for navigating trees.

This is because English sucks at tree relationships. Other languages are much better at this.

For example, Mandarine Chinese has unique words for each side of the family tree (e.g. unique word for Grandma on mother's side vs Grandma on Father's Side), and also a rather logical system to describe how you navigate the tree.

Chinese isn't even unique in this, it is just that English is really really bad.

Or is it that you're referring to other relations than those two having unique words? If so then that would seem to introduce its own problems in ballooning the vocabulary.

Maybe English is just happier with the ambiguity?

I got very tired, very quickly, even as a kid, of saying "Grandma on my Dad's side".

I had two Uncles with the same name, again, "Uncle <foo> on my Dad's side" is a PITA after awhile.

Everyone else doesn't care, shouldn't care.

But yeah, using it systematically (in a non-functional language) is unwise.

But this doesn't change the fact that humans seem to intuitively perceive iteration as more natural.

Like, "space" and "time" can't be understood as two distinct notions, per relativity. But we still perceive them as such on a daily basis.

There are examples of other communities which have invented something pretty much the same as loop syntax, for example you get things which are basically loops in knitting patterns or (less reguarly) in recipes. I have never seen an example of recursion outside computer science/programming.

Also in crochet. A pattern will have instructions like

* (2tr, 3ch, 2tr) all in next 2ch sp; repeat from * 6 times more

where statements like 2tr mean 2 treble stitches and the bit between the * symbols is repeated 6 times

You were a kid in shop class. Now you want your kids to take shop class. Because, recursion.

If you have to make up nonsensical examples to prove your point, then you probably don't have a point.

> You were a kid in shop class. Now you want your kids to take shop class. Because, recursion.

That's not recursion.

  def spawn():
    take_shop_class()
    return spawn()

Int counter_of_sanded_legs = 0;

do{

Sand_a_leg; Counter_of_sanded_legs++;

} While (counter_of_sanded_legs < 4);

Need four legs, have none. Doing while I don't have enough. How many legs do I have? 1. Doing. How many legs do I have? 2. Doing. How many legs do I have? 3. Doing. How many legs do I have? 4. Done.

Alternatively:

for (int i=0;i<4;i++;) {

//how we start; whether we repeat; how we update our counter.

Sand_leg();

}

You only need to sand a leg when you don't have enough legs.

These aren't that far off of actual things you'd do moving about. In fact, not realizing that you're distilling something physical into the symbolic is a leading cause of confusion in my experience.

A "do x times" dedicated looping construct would be syntactic sugar that detracts from understanding what the underlying semantics are; which if you're teaching how to program is a bad idea. The idea is to have your understanding precede the machine. Not lag behind.

You can start screwing around with abstractions after you get the basics. As once you have the basics, you can compose them into any form you want.

The rest is just increasing levels of crippling mental illness.

But take a newbie, and "do this 3 times" in a loop is far more clear than the recursive equivalent.

Sometimes recursion does allow you to reason about code more easily or come to a working solution faster, sometimes it does not.

Measure the concrete: CPU time and memory consumed. Iteration will likely trump recursive methods w.r.t both these metrics. If it doesn't, you can likely transform your iterative algorithm to one that utilizes SIMD (not always).

Let me try: in classical dance, martial arts, or even skateboarding, advanced skills manifest as effortlessness: the movements comes naturally, they're not forced, things just flow.

If you compare a typical functional (recursive + pattern matching, but the point would stand even with a fold) factorial with an imperative one (for loop), the functional approach is more effortless, you have to be less explicit about what's going on. It's more eloquent.

However as you seem to imply, when we're programming, the focus should be on delivering something that works as expected; this particular kind of aesthetic is secondary at best.

Using the beholder's eye, of course.

What culty group even exists around recursion anyway? Can you get me an invitation?

Simplicity is actually a hallmark of this sense of beauty.

Everything else is just abstraction's we're built up to make our lives easier.

If we always jump to the top of the function, or if we jump someplace else, the machine cares not. Just don't blow the stack.