5 ms·

I'm having trouble connecting the opening paragraphs to the examples much at all. A lot of this seems like splitting semantic hairs -- can't we just generalize

by gipp 3y ago

I'm having trouble connecting the opening paragraphs to the examples much at all. A lot of this seems like splitting semantic hairs -- can't we just generalize our applications "State" to include the "Intent"? The text editing example doesn't require "invalid transitions" because there's nothing invalid about the state "desired_column: 6, current_column: 1". Which, BTW, is not to say that this delineation isn't useful as a design idea. The author just seems to be under the impression that this is an argument against... idk, strong typing? Making invalid states unrepresentable? And it just isn't.

dist-epoch 3y ago
> "desired_column: 6, current_column: 1" Maybe this creates confusion? If you are the view, which column do you display?
- gipp 3y ago
  I mean that's just pseudocode to illustrate my point. You'd certainly want a more structured way to express specified vs actual value, not just similarly named fields This is also not a new idea, though I can't recall if there's a name for it. Kubernetes leans heavily on this pattern, for example
jauntywundrkind 3y ago
I hadn't thought about this before today, ht I think there's some interesting terrain we get when we capture intent as something above the state. Capturing the desired column let's us derived an actual column. Instead of programmers having to manage two bits of state & their interrelation, it seems like we can do with managing just intent, and recalculating state each time. Thats a much simpler state machine to manage. This application of Promise Theory / Desired State Management looks a lot like how another vast new part of computing work too: Kubernetes. Capture intent, then devise systems that try best as they can to coerce the current state towards the intended state. Rather than hand wiring each action ourselves, & having a big bundle of state, we can get to see what the actual objective is. The current state is almost incidental, just a logic programming puzzle to coerce into a form truer to the Intent. I haven't totally figured out how all the pieces of this article fit together. I don't know whether Stanley as an archetype of overly fussy controlling dev really informs or helps, and I feel bad about enjoying watching a straw man burn but I do think there's a real hazard some devs go down, of obsessing over control. The idea of state versus intent layers I think does offer some relief, lets us consider more carefully we should allow relaxation of checking & validation. That a good Stanley could grow from, could harness. But I do somewhat miss the connection between Stanley & the rest of the article.
erhaetherth 3y ago
No, because now you have 2 pieces of state to maintain and keep in sync. You must store `desired_column` and compute `current_column`. Otherwise you or someone will try manipulating `current_column` to try to get the desired outcome, or worse, update one and not the other.
- lolinder 3y ago
  So make current column a readonly computed property of the actual state, which is what TFA calls the Intent. What TFA discovered is that anchoring your state closer to the user input is valuable, but that insight doesn't remove functions from your toolbox.

by gipp 3y ago

dist-epoch 3y ago

> "desired_column: 6, current_column: 1" Maybe this creates confusion? If you are the view, which column do you display?

gipp 3y ago
I mean that's just pseudocode to illustrate my point. You'd certainly want a more structured way to express specified vs actual value, not just similarly named fields This is also not a new idea, though I can't recall if there's a name for it. Kubernetes leans heavily on this pattern, for example

jauntywundrkind 3y ago

I hadn't thought about this before today, ht I think there's some interesting terrain we get when we capture intent as something above the state. Capturing the desired column let's us derived an actual column. Instead of programmers having to manage two bits of state & their interrelation, it seems like we can do with managing just intent, and recalculating state each time. Thats a much simpler state machine to manage. This application of Promise Theory / Desired State Management looks a lot like how another vast new part of computing work too: Kubernetes. Capture intent, then devise systems that try best as they can to coerce the current state towards the intended state. Rather than hand wiring each action ourselves, & having a big bundle of state, we can get to see what the actual objective is. The current state is almost incidental, just a logic programming puzzle to coerce into a form truer to the Intent. I haven't totally figured out how all the pieces of this article fit together. I don't know whether Stanley as an archetype of overly fussy controlling dev really informs or helps, and I feel bad about enjoying watching a straw man burn but I do think there's a real hazard some devs go down, of obsessing over control. The idea of state versus intent layers I think does offer some relief, lets us consider more carefully we should allow relaxation of checking & validation. That a good Stanley could grow from, could harness. But I do somewhat miss the connection between Stanley & the rest of the article.

erhaetherth 3y ago

No, because now you have 2 pieces of state to maintain and keep in sync. You must store `desired_column` and compute `current_column`. Otherwise you or someone will try manipulating `current_column` to try to get the desired outcome, or worse, update one and not the other.

lolinder 3y ago
So make current column a readonly computed property of the actual state, which is what TFA calls the Intent. What TFA discovered is that anchoring your state closer to the user input is valuable, but that insight doesn't remove functions from your toolbox.