> even in the sum example, you see the statement "N is n-1"
That wasn't actually what the example said. It said N1 = N - 1, and continued using the N1 value somewhere else. In that example, no actual mutation occured.
It is difficult to understand the full beauty (or horror, depending on your pov) of functional programming with such a simple example. But as you scale up in complexity, it can be someone’s full time job to make sure the model is accurately translated to the computer’s memory. With a pure language, the compiler is responsible for maintaining the mapping to memory, so you (mostly) just focus on the symbolic relationships of your model. This can be extremely freeing once you train yourself to think in functional terms. Of course, there is a performance cost, but this can be managed and in cases where people turn to functional programming reliability and correctness outweigh the cost.
Pure languages still use stack to store mutating state. In a single-threaded programs this is almost non-observable except for occasional stack overflow crashes. But with multiple threads and message passing one can emulate arbitrary state mutation just by using messages and stack.
Then I have found the code that is a heavy user of closures is harder to understand even if it is single-threaded and closures can pass arbitrary state even if the state is immutable.
What I have found useful is persistent data structures. Those really simplify modelling. But then those can be used in imperative languages as well.
It is declaring a relationship, between the previous value and the current. One way or another, youre defining transformations.
I mean even in the sum example, you see the statement "N is n-1" which is the exact same thing as x = x+1 with = swapped for "is"