In recursion you don't necessarily have to think about self reference. Instead simply think of the return value of the function.
I think the only time I use recursion in Haskell is when I need to mutate some parameters over a set of items (which is often) but I don't have to think about the fact that the function is recursive - I only have to ask myself "how do the parameters change while traversing the set?"
Lastly, if you don't like the idea of recursion you can often do the same with a fold by keeping your parameters in the accumulator as a tuple or other such sum type.
My main point being that none of these things (programming patterns and strategies) are intuitive until you have some background.
>My main point being that none of these things (programming patterns and strategies) are intuitive until you have some background.
That's my point. I'm saying in addition to this, loops are by far one of the easier patterns and strategies to become familiar with.
think about it. By knowing what a function is... recursion can be taught as a logical next step without introducing any additional language primitives. Yet most computer science classes will still teach looping syntax before even touching upon recursion. Why? Because looping is way easier to grasp then recursion, theoretical elegance be damned.
I'm saying that most people are biased towards loops and mutation because they learned them first. It's like riding a skateboard vs riding a bike. They're equally challenging if you know neither.
>I doubt that. Loops are way more intuitive than recursion.
Linked individual is my coauthor. She finds recursion far more intuitive than loops and mutation, so - don't doubt.
It's also easier to write recursion out on paper in a way that is faithful to the program semantics. Loops require tracking state off to the side.
Debating this point is useless. Operating a crane is not more natural than picking a pile of dirt up in your hands and carrying it. It's more efficient anyway.
I think the only time I use recursion in Haskell is when I need to mutate some parameters over a set of items (which is often) but I don't have to think about the fact that the function is recursive - I only have to ask myself "how do the parameters change while traversing the set?"
Lastly, if you don't like the idea of recursion you can often do the same with a fold by keeping your parameters in the accumulator as a tuple or other such sum type.
My main point being that none of these things (programming patterns and strategies) are intuitive until you have some background.