C loops are natural and easy to understand for programmers who were trained on loops. I doubt that tail recursion is any harder to get for students who don't have that background. Would be an interesting experiment though.
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
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.
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()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.
Simplicity is actually a hallmark of this sense of beauty.
What culty group even exists around recursion anyway? Can you get me an invitation?