I had to drop out for a month to deal with taxes and keep porting this site. I’m catching up, and this article is a meandering mess that goes nowhere, so, if you value your time, don’t even read it.
I was porting the Hamurabi code to run with React, built the UI, and got a little confused about where to keep game state. Many coders seem to have this problem, according to the tutorials.
The short, obvious, answer was that this is a turn-based game, and the game is an array of turns. This was already worked out in the port, because it was easier to clone the game logic by 1) writing tests and 2) turning the game logic into functions.
A single object holds the entire turn state, and each turn is saved in the array of turns. You can then go back and forth in time, and “replay” the game, or undo a turn.
If you replace the random number generator with a predictable stream of non-random numbers, you can then test the entire game. This is basic OOP.
The game state should be external to the UI, and outside of React.
“Duh,” right?
Forward into the past
Then, my friend sent me a link to this Quora answer by Alan Kay, and in the article, he talked about how John McCarthy (inventor of Lisp) thought about race conditions and state.
A conflict was between at (robot, philadelphia) and at (robot, new york) which could not happen simultaneously, but could happen “over time”. This was like the problem of contemporary programming where variables would be overridden (and sometimes even files) — basically, letting the CPU of the computer determine “time”.
This destructive processing both allows race conditions and also makes reasoning difficult. John started thinking about modal logics, but then realized that simply keeping histories of changes and indexing them with a “pseudo-time” when a “fact” was asserted to hold, could allow functional and logical reasoning and processing. He termed “situations” all the “facts” that held at a particular time — a kind of a “layer” that cuts through the world lines of the histories. cf McCarthy “Situations, Actions, and Causal Laws” Stanford, 1963 prompted by Marvin Minsky for “Symbolic Information Processing”.
Go back and read that article. It’s good. All his articles are good.
What synchronicity! Obviously, thinking about time, mutability, and immutability is the zeitgeist.
As usual, I missed this trend. It’s kind of embarrassing, because I still <3 functional style programming within non-FP languages like C, PHP, JS, etc. I don’t mean going all the way with FP, but… mixing it up a bit.
To Read and View
https://medium.com/@machnicki/why-redux-is-not-so-easy-some-alternatives-24816d5ad22d