[taeric]

This is a hill I will die on. Probably literally. If you are writing in a metaphor of equations, than yes, mutation is almost certainly going to bite you. If you are writing in a metaphor of process, you almost certainly want to manage, as you say.

I feel that early texts were good at this. Turtle Geometry is my personal favorite book in this vein. I seem to recall we spent a long time going over how to double buffer graphics so that you could be working on one buffer while letting the system draw the other. Not sure what texts we used for that, back in the day.

Later texts, though, go through a lot of hurdles to hide the fact that things are actively changing. The entire point is to change things.

[mrkeen]

> The entire point is to change things

We've other 'entire points' along the way.

Allocation and freeing of memory are fundamental to computing. We don't do malloc and free any more.

Control-flow (selecting which instruction to follow next) is also fundamental. We don't to goto anymore.

[taeric]

I'm not entirely clear what you mean. I can easily see malloc/free in the realm of "incidental complexity." Many of the abstractions in process descriptions are absolutely not incidental, though?

Control-flow is an awkward choice there, as goto is not necessarily fundamental for how control-flow is run for a lot of code. And I have absolutely used labeled break/continue in Java before for a control loop that ran great until people tried to refactor to use more indirect control.

I also think it is interesting as I greatly prefer code where you can do basic left/right and top/down reading to know what is intended by the code.

At any rate, my original intent was to discuss code that is controlling something works really well if you embrace a metaphor for the code you are in.