I is for Intent

Maybe this creates confusion? If you are the view, which column do you display?

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.

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.

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.