Recursion is also producing results that are "wrong answers" although I prefer to call them partial results. Just like a loop that is producing partial results as long as it has not finished yet.
I'd also think looping is far closer than recursion to how we tend to manually calculate things (either entirely in our heads or using a pen & paper or even a basic calculator).
(Edit: looks like a number of other posters have made the same point already, but in dead/downvoted posts, not sure why...)
The issue is that recursion in software development is relatively rarely about arithmetic operation. For example, you might want to traverse a tree of objects (like a filesystem folder) to run some operation on them, etc.
In this case the intermediate information is pointers to where you are currently processing various folders in your tree structure, etc. In a loop you would have to create a data structure to hold these. In recursive function this would typically be spread in multiple frames on your stack pointing to objects in your heap.
And yes I'm very much in agreement that the real power of recursive algorithms is when working with tree-like data structures.
Perhaps? But this would be like asking if there was a chipset that can work without branching because of someone mentioning "GOTO bad".
> I'd also think looping is far closer than recursion to how we tend to manually calculate things
It's not the looping I mind, it's the mutation.
Not true. If you share your copy of:
answer = sum [1..10]
answer = 3 + sum [3..10]
answer = 6 + sum [4..10].
"But can't you just hide the partial result until it's ready?"
Sure. Get rid of class fields and getters(). I'm happy to. Are you?
And yes, if you do have that exceptional case of a complex algorithm that needs to store partial results in ivars as they are required by different methods and inconvenient to pass around individually, those ivars tend to not be exposed.
In fact, you'd more likely create a separate context object that you pass around, so also not visible externally.
Cool! Then it follows:
If a result is not temporary, then it can be immutable. Properly immutable, not just final.
If a result is temporary, then it is not to be visibly external at all. Not as a field, and not via any getter.
I could live with that.
s = 0
i = 0
// Invariant: before and after every iteration, s is equal to sum of [0..i]
// End condition: i == n
while i != n:
s += i
i += 1
// Here, i == n and so s is a sum of [0..n] because the invariant still holds