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.
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.
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.
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.
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
> What is the caret state in the middle? It is both column 1 and column 6.
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?
Is it hard to teach "Intent", because the treatise here isn't well thought out?
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 don't know, I've met a lot of devs who've found the "true religion" of strict data integrity and have been reluctant to allow for the messier practicalities of user- and externally-sourced data.
None of them called Stanley, but there's definitely a fairly common pattern I recognise.
> 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 their 30-year coma. Before introducing them to all the LGB+ (don't push them too quickly!) acceptance progress that's been made in that time...
I think maybe the author was casually mocking their strawperson Stanley (who they effectively characterized as old), by also associating him with other ideas widely considered outmoded and shameful.
Ironically, if Stanley's experience originated as an Internet-savvy techie of 30 years ago, that would be of the "on the Internet, nobody knows you're a dog" era, when people who were gay, trans, or of other marginalized groups, could go online and find places where they can be accepted. Stanley supported trans friends before most people even knew that was a thing.
Or, if we're still trying to link older with wronger, go back to Stanley's counterculture hippie parents, who were more progressive than today's typical holder of now-fashionable ideas.
The author discusses their actual ideas at length. I think they went a bit off-track throughout the piece, when distinguishing their ideas from some current model, accidentally straying into tactics of propaganda rather than reason. And incidentally contributing to ageism.
This article is very interesting. I have previously noticed the contrast between strict state representations, and the messier practicalities of user- and externally-sourced data.
I like the insight of splitting Intent and State. There's a lot to the article & I'm not sure I fully understand the latter half yet, but I'm filing this one away for further exploration.
Same here, and I am disappointed to not see much discussion here about the article.
Last year I was working on a multiplayer web game for the first time and I found it very difficult to devise a solution accounting for the fact that player 1 has different state to player 2, which has different state to the backend. I arrived at a solution which entailed sending sequenced commands, but having read this article I now realize that it was the explicit notion of intent that I was searching for.
> He's a big fan of pattern matching, and enums, and discriminated unions, which allow correctness to be verified at compile time.
And the forest for the trees:
> [Stanley] hates any source of uncertainty or ambiguity
> [the author argues] this view of software is not just wrong, but fundamentally incompatible with the real world.
The author paints a picture of someone who chooses these tools not because they are nice tools or because the tools are helpful but because of desires that stem from misguided, dogmatic, unhelpful beliefs that make the subject a worse engineer.
By contrast, you are probably a lovely person who loves writing nice code. This article has nothing to say about you.
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.