There's nothing wrong with recursion per se. Recursive algorithms are easier to program (and the code is easier to read) than if I were to translate it into an iterative algorithm. There are benefits in having code that's easy to read and write.
There certainly is an overhead in allocating stack frames for each recursive call, but whether that's worthwhile working around is a different question. Writing something like QuickSort iteratively would involve setting up additional data structures (a stack) as well, so that too has a certain amount of overhead.
The overhead becomes sizeable when the problem is tree-recursive (i.e., involves more than one recursive call per step) and goes to great depths. Fibonacci numbers are a good example of when using recursion is the wrong thing to do - the iterative approach has linear complexity, while the recursive approach has exponential complexity, in addition to the stack frame allocation overhead.
in all seriousness, the answer to this question is the same as the answer to ANY question about software development - you need more info. What is important on this system? What constraints do you have?
If memory is an issue (i.e. a phone or hand-held device application), recursion might not be very wise, especially (as Ulf says) you're going to get pretty deep.
However, the logic for recursion can be simpler, so maintenance and development might be easier. Maybe there are well known recursive algorithms that are well documented already, while you'd have to 'roll your own' non-recursive solution.
"Why would you use other logic when you can write recursive a function?"
1. Recursion will be bad for code readability - not every programmer can understand it. 2. Recursion is a repeated method call stack - the more you use recursion the more memory stack created 3. Recursion can not be inlined by compilers - if i am not wrong.
1. Recursion will be bad for code readability - not every programmer can understand it.
That depends on whether a straightforward non-recursive algorithm exists. Programming a recursive algorithm using recursion will certainly result in easier to read code than the same algorithm programmed in a non-recursive way.
As an example, compare recursive and non-recursive QuickSort implementations.
Several.I am listing 2: 1) When we learn coding for mathematical functions like n! (factorial).The coding is much easier and in fact more readable. 2) XML processing : Well, these are in essence mathematical function only, but not that apparent from the surface.So, when you have to process repeating nodes in a XML document, recursion is a boon.Or so I find.