User:Thijshijsijsjss/Human Parser/About Signalling

This annotation is about giving some insight into the programming (philosophy) of the game, and relating that to a personal anecdote. I have yet to live this anecdote. Once that's in place, I think I'll condense / clean up the text that's already there.

[disassociative anecdote, me waiting - (unavailable and apologetic?)]

In programming, often two agents A and B rely on each other. For example, A and B are processes and B needs to happen only after A has finished. Or A and B are physics objects and B is activated only when colliding with A. Or A and B are humans, dependent on each other. There must be a way for A and B to communicate about this event.

A typical way of going about this communication is an 'observer pattern': B 'observes' A, to continuously check if it needs to do something. This makes B very passive, waiting patiently on A, and spending all their resources in a paralyzing state of monitoring. Reversly, A is forced to be intruded, always being watched. There's a lot of pressure on A's availability: if A were to be unavailable, B would crash.

An alternative to this is signalling: instead of A being observed constantly by B, A will shout whenever it's ready, and B will react accordingly. By doing this, the communicative channels are essentially reversed. A is freed from constant observation. B has a lot more autonomy, being able to do what it wants or needs, while not having to monitor A. Additionally, because B is not reliant on A, signal communication doesn't cause runtime crashes when the connected object is removed. This allows for great decoupling, and means even more autonomy: A doesn't need to be available at all times -- and doesn't need to apologize for that.

[me shouting]