<story><title>Dijkstra was right – recursion should not be difficult</title><url>https://blog.angularindepth.com/learn-recursion-in-10-minutes-e3262ac08a1</url></story><parent_chain><item><author>jerf</author><text>&amp;quot;This task can also be solved using iterative solution, but it’s way more complicated because we would have to nest for loops but don’t know how deep they are nested. The unknown number of nested loops is a common characteristic of all problems that are recursive in their nature and should give you a hint that recursive solution is required.&amp;quot;&lt;p&gt;Would suggest instead something like&lt;p&gt;&amp;quot;We could solve this directly by managing our own stack of work done and keeping track of where we are in the problems as we divide them up, but it&amp;#x27;s easier to take advantage of the fact that the programming language is already providing us a call stack that can do this work for us.&amp;quot;&lt;p&gt;Then, later, you can point out that this also helps with the backtracking solution as the programming language is maintaining the old environments; if you were iteratively managing your own stack you&amp;#x27;d also have to backtrack manually.&lt;p&gt;Because that&amp;#x27;s how you transform a recursive call into an iterative one, not nested for loops. The general points made in the article still hold up, of course.</text></item></parent_chain><comment><author>edmccard</author><text>&amp;gt;Because that&amp;#x27;s how you transform a recursive call into an iterative one, not nested for loops.&lt;p&gt;I came to understand recursion through nested for-loops, though, but that might just be a historical accident. In the summer of 1988 I had written a Mastermind solver in Microsoft Quickbasic[1] for the specific case of 4 &amp;quot;pegs&amp;quot;. At each guess, I used for-loops nested 4 deep to build a structure representing the possible remaining solutions (for all possibilities of the first peg, check all for the second peg, etc.) Then I wanted to extend it to work with variable numbers of pegs; after spending most of that summer trying to figure out a loop-based solution, I discovered that subroutines could call themselves and it hit me that I could have a function that took the possibilities already computed for a peg, and then called itself with those applied to the next peg.&lt;p&gt;So I&amp;#x27;ve always thought of recursion as a way to have arbitrarily deeply nested loops.&lt;p&gt;[1] Believe it or not, it did support recursive functions!</text></comment>
<story><title>Dijkstra was right – recursion should not be difficult</title><url>https://blog.angularindepth.com/learn-recursion-in-10-minutes-e3262ac08a1</url></story><parent_chain><item><author>jerf</author><text>&amp;quot;This task can also be solved using iterative solution, but it’s way more complicated because we would have to nest for loops but don’t know how deep they are nested. The unknown number of nested loops is a common characteristic of all problems that are recursive in their nature and should give you a hint that recursive solution is required.&amp;quot;&lt;p&gt;Would suggest instead something like&lt;p&gt;&amp;quot;We could solve this directly by managing our own stack of work done and keeping track of where we are in the problems as we divide them up, but it&amp;#x27;s easier to take advantage of the fact that the programming language is already providing us a call stack that can do this work for us.&amp;quot;&lt;p&gt;Then, later, you can point out that this also helps with the backtracking solution as the programming language is maintaining the old environments; if you were iteratively managing your own stack you&amp;#x27;d also have to backtrack manually.&lt;p&gt;Because that&amp;#x27;s how you transform a recursive call into an iterative one, not nested for loops. The general points made in the article still hold up, of course.</text></item></parent_chain><comment><author>unclebucknasty</author><text>&amp;gt;&lt;i&gt;Would suggest instead something like&lt;/i&gt;&lt;p&gt;Honestly, I think your version is &lt;i&gt;less&lt;/i&gt; clear on its own in that it obscures the main point of that particular statement: when it&amp;#x27;s best to consider recursion instead of nested loops.&lt;p&gt;In other words, the original is a statement about &lt;i&gt;why&lt;/i&gt; or &lt;i&gt;when&lt;/i&gt; to use recursion, while yours is a statement about &lt;i&gt;how&lt;/i&gt; recursion helps.&lt;p&gt;It&amp;#x27;s great complementary background though.</text></comment>