There's a sort of semantic shell game happening here, though. It's like:
1. Understanding the code is hard.
2. So instead we'll use these event things and you only need to understand the events.
3. And events are so great that we'll design a language around them and implement the whole program using them.
Step 3 is equivalent to step 1 now, except that instead of "statements" and "expressions" you have "events" and "yields". It's still "the code" for any meaningful definition. It's an authored system with behavior that you need to understand before you can profitably modify it. All you've gained now is that instead of textual code you can read and at least somewhat reason about statically, you have a dynamic stream of events coming from who-knows-where and you have to somehow hold the entire possible state space of them in your head in order to add new code that patches them on the fly.
> Obviously to not have the water jump to hot or code by 3 units before it gets to lukewarm, but to incrementally make it lukewarm.
Obvious to whom? What is to prevent some future maintainer from breaking that requirement when they bolt on their change?
There was clearly a previous requirement to have the water jump to cold by three units. Is that requirement null and void? How do we know?
Sure. The author doesn't communicate their idea their well, but it's an interesting suggestion (even if not practical at large). It's not far to what some protocols/systems do (though they do it at a higher abstraction that the code level).
>Obvious to whom? What is to prevent some future maintainer from breaking that requirement when they bolt on their change?
Nothing. What is to prevent some future maintainer from breaking that requirement when they bolt on their change on any other codebase? As long as one has access to source, they can break any and all kinds of contracts and requirements trivially.
>There was clearly a previous requirement to have the water jump to cold by three units. Is that requirement null and void?
That requirement (or function) never went anywhere. As the post explains, the new functionality is only triggered when the water level is low (and the old is untouched).
"The b-thread from before remains untouched. We added a new one to the right. For now there’s nothing surprising. The behavior of this program (compromised of these 2 b-threads) is that whenever “waterLevelLow” happens, we add hot 3 times and then add cold 3 times."
A bunch of stuff:
* A cultural expectation that you understand what the existing code does before you change it.
* Seeing the tests and documentation for the code when you're in there.
* Having to physically delete some existing code in order to remove functionality, which forces you to reckon with that choice.
I mean, the general thesis of the article is "here's a methodology that allows you to add stuff to a program without understanding what it does". And my claim is that that's bad goal in the first place because it means you can discard behavior users rely on without realizing it.
Which you could do by checking the "event source" for the old commands.
I think the idea is that the system is a black box (you don't care for the implementation) and everything happens through those events, e.g. like through commands in the GoF Command pattern. By studying the existing commands issued, and by being able to interject new ones and block old ones you can change the system without caring about the implementation of those commands.
The way the overall system is described (both for the water example and the ATM) is that the system is also kind of immutable and composed of atomic facts, where e.g. a counter action -X will revert a previous +X action (e.g. if you have 3 "add hot water" commands, you can issue 3 "remove hot water" commands to cancel them out).
>Finally, the third b-thread is added that interacts with the two previous ones to cause the hot and cold water adds to be interleaved. What requirement does that meet?
Obviously to not have the water jump to hot or code by 3 units before it gets to lukewarm, but to incrementally make it lukewarm.