6 ms·

You might be able to trace the execution of the iterative code more easily, but in my experience it is often much less clear why that produces the correct resul

You might be able to trace the execution of the iterative code more easily, but in my experience it is often much less clear why that produces the correct result and how that code was written in the first place. Take a look at the wikipedia page for computing Levenshtein distance: https://en.wikipedia.org/wiki/Levenshtein_distance#Computing_Levenshtein_distance https://en.wikipedia.org/wiki/Levenshtein_distance#Computing... The recursive version needs barely any explanation. But ask me to carry it out by hand and I'm sure I'll pretty quickly get lost. The iterative version needs a lot more explanation for why it is the way it is, but I also think I could carry it out on paper quite easily.

ghettoimp 8y ago
Very much agree. If you are working on any kind of tree structure, graph, parse tree, etc., recursion can be really beautiful and clear. My theory: folks like iteration because 90% of the "for" loops they write are really just "foreach".
- bogomipz 8y ago
  >"folks like iteration because 90% of the "for" loops they write are really just "foreach"." I didn't understand this comment. What do you mean by "for vs foreach."? Can you elaborate?
  - bkdonline 8y ago
    I guess the foreach is where each iteration has independent operation, vs a generic for loop where this iteration depends on result of the previous iterations.
blackflame7000 8y ago
I mean if you label all your variables i,j, and k and use minimal formatting or bracketing then I see your point it is harder to read. Whats complicated about an iteration. If it works properly after the first one chances are it will continue to work for the millionth one. If you see problems, its because something is modifying it between runs, but that wasn't a fault of the iterative strategy, it was the fault of a bad programmer. Conversely, you must always make sure the stopping condition and all base cases are met during recursion. Forget one corner base case and you got a rare production bug.
- kolpa 8y ago
  In an iterative solution, you have to get your loop conditions correct, and you have to create a bunch of inputs before you know how you are going to use them, sort of a "solution in search of the problem". Recursion takes a problem and expresses it terms of similar, but smaller, unsolved problems, unless you can solve it directly (base case). It's a "problem in search of a solution", that always makes progress (unless you have a bad algorithm, as always). If a recursive solution works on a small input, it will work on a big input. If you missed a base case, you'll see it immediately because trivial (literally!) input will make your solution fail to terminate. In production, the main problem with recursion is stack size limits (or more generally memory limits) if you can't/don't use tail-call elimination.
- throwaway37585 8y ago
  > Whats complicated about an iteration What’s complicated about a recursion? > If you see problems, its because something is modifying it between runs, but that wasn't a fault of the iterative strategy, it was the fault of a bad programmer. > Conversely, you must always make sure the stopping condition and all base cases are met during recursion. You seem to be applying a double standard here. > Forget one corner base case and you got a rare production bug. Base cases are usually much easier to reason about.
  - blackflame7000 8y ago
    Then why does NASA consider it unsafe for mission critical code? How about unknown potential stack size? How about factoring a large number with recursion? Everything recursive can be transformed to iterative and yea sometimes it’s not as sexy but neither is a helmet https://www.reddit.com/r/programming/comments/3dnsh1/nasas_ten_coding_commandments/ https://www.reddit.com/r/programming/comments/3dnsh1/nasas_t...
    - throwaway37585 8y ago
      > Then why does NASA consider it unsafe for mission critical code? They also proscribe unbounded iterations (point 2). In any case, NASA’s guidelines for mission-critical code are not necessarily good guidelines for general software engineering, given the constraints involved. It’s also worth noting that recursive solutions are probably more amenable to static analysis and automated theorem proving. > How about unknown potential stack size? If stack size is a problem, try an iterative solution. > How about factoring a large number with recursion? Go with iteration. You keep editing your answer to add more cases where iteration is the way to go. I’m not disputing there are use cases where iteration is appropriate.

ghettoimp 8y ago

Very much agree. If you are working on any kind of tree structure, graph, parse tree, etc., recursion can be really beautiful and clear. My theory: folks like iteration because 90% of the "for" loops they write are really just "foreach".

bogomipz 8y ago
>"folks like iteration because 90% of the "for" loops they write are really just "foreach"." I didn't understand this comment. What do you mean by "for vs foreach."? Can you elaborate?
- bkdonline 8y ago
  I guess the foreach is where each iteration has independent operation, vs a generic for loop where this iteration depends on result of the previous iterations.

blackflame7000 8y ago

I mean if you label all your variables i,j, and k and use minimal formatting or bracketing then I see your point it is harder to read. Whats complicated about an iteration. If it works properly after the first one chances are it will continue to work for the millionth one. If you see problems, its because something is modifying it between runs, but that wasn't a fault of the iterative strategy, it was the fault of a bad programmer. Conversely, you must always make sure the stopping condition and all base cases are met during recursion. Forget one corner base case and you got a rare production bug.

kolpa 8y ago
In an iterative solution, you have to get your loop conditions correct, and you have to create a bunch of inputs before you know how you are going to use them, sort of a "solution in search of the problem". Recursion takes a problem and expresses it terms of similar, but smaller, unsolved problems, unless you can solve it directly (base case). It's a "problem in search of a solution", that always makes progress (unless you have a bad algorithm, as always). If a recursive solution works on a small input, it will work on a big input. If you missed a base case, you'll see it immediately because trivial (literally!) input will make your solution fail to terminate. In production, the main problem with recursion is stack size limits (or more generally memory limits) if you can't/don't use tail-call elimination.
throwaway37585 8y ago
> Whats complicated about an iteration What’s complicated about a recursion? > If you see problems, its because something is modifying it between runs, but that wasn't a fault of the iterative strategy, it was the fault of a bad programmer. > Conversely, you must always make sure the stopping condition and all base cases are met during recursion. You seem to be applying a double standard here. > Forget one corner base case and you got a rare production bug. Base cases are usually much easier to reason about.
- blackflame7000 8y ago
  Then why does NASA consider it unsafe for mission critical code? How about unknown potential stack size? How about factoring a large number with recursion? Everything recursive can be transformed to iterative and yea sometimes it’s not as sexy but neither is a helmet https://www.reddit.com/r/programming/comments/3dnsh1/nasas_ten_coding_commandments/ https://www.reddit.com/r/programming/comments/3dnsh1/nasas_t...
  - throwaway37585 8y ago
    > Then why does NASA consider it unsafe for mission critical code? They also proscribe unbounded iterations (point 2). In any case, NASA’s guidelines for mission-critical code are not necessarily good guidelines for general software engineering, given the constraints involved. It’s also worth noting that recursive solutions are probably more amenable to static analysis and automated theorem proving. > How about unknown potential stack size? If stack size is a problem, try an iterative solution. > How about factoring a large number with recursion? Go with iteration. You keep editing your answer to add more cases where iteration is the way to go. I’m not disputing there are use cases where iteration is appropriate.