Re:B-threads: programming in a way that allows for easier ch...
by munificent on Monday July 29, 2019 @08:56PM
(#20561117)
> What is to prevent some future maintainer from breaking that requirement when they bolt on their change on any other codebase?
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.
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."