A bit late to the discussion, but this has deep connections. As a programmer, your job is provide business invariants using complexity management techniques. And checking that your state space is small is a tool with gigantic payoff.
Maintaining a small state space it why we want to let it crash. Each program instruction can potentially multiply the number of states possible. Erlang even has this whole "Let It Crash" philosophy as a guideline [1].
Maintaining a small state space is how you tame concurrent programs, where adding one thread can cartesian-product your state space. But there are tools like TLA+ which can help you build proofs over this state space. And build invariants that your threads can use safely. Hre is a visualizer of that state space [2]. Notice any resemblance to the graphs you just saw in the video?
Programming sometimes feel like this "Rush Hour" puzzle.
Maintaining a small state space it why we want to let it crash. Each program instruction can potentially multiply the number of states possible. Erlang even has this whole "Let It Crash" philosophy as a guideline [1].
Maintaining a small state space is how you tame concurrent programs, where adding one thread can cartesian-product your state space. But there are tools like TLA+ which can help you build proofs over this state space. And build invariants that your threads can use safely. Hre is a visualizer of that state space [2]. Notice any resemblance to the graphs you just saw in the video?
Programming sometimes feel like this "Rush Hour" puzzle.
[1] https://wiki.c2.com/?LetItCrash [2] https://prob.hhu.de/w/index.php?title=State_space_visualizat...