11–20 of 23 posts
The article starts with building a straw person, Stanley (who is weirdly homophobic for some reason?), and doesn't really articulate "here's how you code with intent" and "why coding with intent is important". Instead, it tries to tear apart people who don't use intent.
I made it all the way to the caret position before I realized my intent was completely wrong.
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 usefu…
Maybe this creates confusion? If you are the view, which column do you display?
The author goes off the rails at precisely this point. The cursor state is column 1, the cursors return column is 6. Congrats, you've made a blog post about a problem that could be solved using a tuple.
There's better ways to tack into the invalid states are unrepresentable mantra. For example, cursor column should never be greater than len(line[cursor_row]). How should such a constraint be encoded into the type system?
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 usefu…
> "desired_column: 6, current_column: 1" Maybe this creates confusion? If you are the view, which column do you display?
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
> Stanley can't dismiss this as just frivolous UI polish for limp wristed homosexuals. … ???
I know. This author is writing from a pretty weird place, especially if they're first categorizing fictional "Stanley" as backend Engineer.
> I chose a text editor as an example because Stanley can't dismiss this as just frivolous UI polish for limp wristed homosexuals. Well, that's... a choice of language. Anyway, I suppose I'd better go check exactly when in the '90s this was originally written, and put a comment suggesting that the year be added to the HN title. ... 2024 Huh. Well, I suppose we should congratulate the author for having woken from thei…
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 usefu…
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.
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 usefu…
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.
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 usefu…
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.