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.
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?