| Recursion is perfectly ok when the code is not mission critical, for example for rapid prototyping. Recursion is A BIG ERROR for mission critical software because it needs variable memory in the stack that depends on the implementation and depends on the other memory on the stack(depending on where it is called), creating stack overflows, breaking completely the system. This means that you write software today for a car, it works fine. Tomorrow you reuse it for a motorcycle and only on specific cases it breaks dramatically, because the motorcycle people used another debugger or another OS with different assumptions. Now when you debug something, you expect errors, and errors in the new code. But when something already runs and fails sporadically, it is extremely difficult to isolate the bug, because you can't see the bug but the cascade consequences of the bug. "What if the solution using recursion results in more readable or declarative code?" Recursion is something that looks perfectly ok in code,on paper could look gorgeous, but could fail terribly in the implementation. The judge is not interested, when you say to her: yeah, it broke and killed someone, but it looks ok in the code! "(especially with languages/compilers that do tail-call optimization properly?)" If compilers were perfect, it will be no problem. On real life no compiler is perfect. We design compilers and they are pretty stupid, it is really hard to represent all the complexity of the world for any given possibility in a compiler. |