I noticed when trying to create a pipeline-style 2d programming environment you have to model IO. Functional programmers do it. If you model it, you can see where the pipeline is communicating to the outside world. If you can’t see it, it’s hidden and you have magic you can’t control.
We have other things our programming languages hide from us to avoid overload. CPU time, memory, the stack, the thread, and the global variable namespace, to name a few.
Indeed, exceptions seem to be a way of getting around the absence of an explicit stack. A couple of months ago at work, I noticed we had a thread-local variable context set and cleared.
All code paths were supposed to clear it, but it didn’t always clear it. I created another thread local variable context_is_set, at the point context was supposed to be cleared.
I added a check for unset context_is_set in the code setting context. Failure meant creating an exception and printing the stack trace to the debug log. One day of running in production told me exactly where to add code to clear context.
An explicit stack would’ve meant I wouldn’t’ve had to create the exception. I could have searched stack for the location where the context variable was cleared. Not finding it would mean printing the stack trace.
Two-dimensional graphs could free us from text. We could model the stack more clearly. Perhaps we could use colour contrast to de-emphasize the irrelevant.
A modeled CPU could allow things like trial threads…