Loops or recursion?

Question

Programming

From the point of view of the theory of computational processes, a program with recursion can be replaced by an equivalent program with cycles.
Which alternative is preferred in programming?
What is easier to write, read, maintain?
In order not to divert the topic towards code efficiency, let's assume that the task is not deep compared to the size of the stack. Or the compiler supports tail recursion.

Answer 1

Everything depends on the task. Sometimes a simple loop is enough, it is easier to work with it and there are no problems with the stack. Still, it’s better to solve problems in a cycle, where the result of the next one completely depends on the result of the previous one (for example, factorial).
For other tasks (for example, crawling nested directories), when each has a number of its own individual variables (for example, the number of files in a given directory), or asynchronous streams, it will be easier to support recursion. Yes, and recursion in this case will be more convenient, because the traversal of one directory does not depend at all on the results of the traversal of another neighboring directory, and they can work in parallel, independently of each other. And then at the end they just combine all their results.
Recursion will also be effective if the recursive function is cacheable, for example, it remembers the result and the cached version is simply returned on the next request.

Answer 2

Use whatever is more convenient. If the implementation is obvious in terms of a loop, then recursion should not be used. And vice versa. So, if you think of solving a problem as a functional dependence (even for the same factorial), then recursion will help you. It will allow you to separate one calculation from another, which relies only on the result of the first. However, if you clearly see what exactly should be done with the variables of the previous iteration in order to get the next result, then the loop will be easier to organize.
Again, it is easier to maintain the code in which the logic is clearly visible (this assessment is subjective).
Ask yourself the question: what is a factorial? “n!=n*(n-1)!, if n>1; n!=1 otherwise" or "n! there is what you get by multiplying 1 in a row by 2, by 3, by 4, ..., by n "
Or this: which option comes to you first if you want to sum the elements in a dynamic list? Create a pointer, go through the list to the end and add to the variable until the pointer becomes null? Or sum the first element with the sum of the tail (if it is not empty)?
For each task, the first option that comes to mind will determine what you are closer to, what will be more convenient for you to use, what will be easier to read.

Answer 3

If one thing were preferable to the other in all cases, this other would not exist.

Answer 4

In academic programming, of course, recursion is more appropriate, since the code turns out to be more beautiful and sometimes clearer.
But in practical programming, in my opinion, there is almost no place for recursion, since in some places it is difficult to debug and + problems with the stack.

Answer 5

There is a third option: generic functions that work with lists (arrays). map f lapplies the function f to each element of f and returns a list of results. filter p lreturns a list of elements for which condition p is true. fold f l"collapses" the list by placing the function f between its elements. Most loops in iterative code can be reduced to these functions. And if the programmer understands how they work, he no longer needs to debug the code with his eyes (either in the case of a loop, or in the case of recursion).
It is only necessary that the language supports working with functions as with values. And anonymous functions do not interfere (labda expressions according to scientific).

Answer 6

In the CLR, tail is slower than call, even in languages ​​where it is supported.
Well, you have to be very confident in yourself to say that any “task is not deep compared to the size of the stack” will always be so and will remain so under any conditions, I would not risk unnecessarily.