<center>
<iframe width="560" height="315" src="https://www.youtube.com/embed/HXNhEYqFo0o" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen><img src='https://img.youtube.com/vi/HXNhEYqFo0o/maxresdefault.jpg' alt='share-with-dlike.jpg' /></iframe></center>

#####

 <p>The topic might be slightly esoteric to some people, but what Brailsford describes is how the software industry finally settled on how the problem of "recursion" should be addressed in higher level programming languages.</p><p>Instead of tackling the problem from the perspective of general recursion, to deal with high level <a href="https://en.wikipedia.org/wiki/Ackermann_function">Ackermann functions</a>, different languages went about it different ways.</p><p>One way is to implement fake recursion that doesn't keep track of each individual step of recursion. &nbsp;This might be useful for certain situations, but not the right way to go about it. &nbsp;It's a "broken recursion" functionality.</p><p>Another (hypothetical) way is to try to implement "general recursion" to try to fully implement Ackermann functions, which was (and still is) not feasible.</p><p>All this to say, the wrong way to go about it would be to say, "We cannot fully implement Ackermann, therefore we won't implement any of it."</p><p>The way they settled on was to implement "limited recursion," which would fulfill most requirements. &nbsp;Basically, they applied practical limitations on these high-level languages. &nbsp;Maybe it would take a lot of memory. &nbsp;Maybe it would take a lot of time. &nbsp;It depends on what you're doing and what your resources are.</p>  

#####

 <center><br><a href='https://www.youtube.com/watch?v=HXNhEYqFo0o'>Source of shared Link</a><hr><br><a href='https://dlike.io/submit.php'><img src='https://dlike.io/special/dlike-logo.jpg'></a></center>