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.
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.
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.
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
… ???
None of them called Stanley, but there's definitely a fairly common pattern I recognise.
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...
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.
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.
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.
Funny, the language that made me a fan of pattern matching was Elixir.
> 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.
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?
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.
