The author doesn’t really refute their strawman Stanley. The strawman’s attributes:
Senior software engineer
Opinion: invalid states should not be representable
Opinion: strong types are good, static types are good
Opinion: exhaustiveness checking for switch/case is good
Opinion: errors should be handled, logged, and avoided
Opinion: databases should be ACID, foreign keys are good, transactions are good
Opinion: plaintext markup (without grammars) and untyped JSON (without schemata) are bad
Hard-to-work-with asshole
Dislikes homosexual folks
Stanley ought to stop being a bigot, but otherwise seems like somebody whose experience has taught them that certain patterns are difficult to maintain over time. The author’s insight about intents is easy to merge with Stanley’s opinions: require intents to be statically typed and schematized, and suddenly there are no conflicts. For example, input devices have a finite collection of possible input messages which all derive from some schematic layout; input devices can be statically typed.
To be precise, this line is wrong:
New intent is a mixed function of both previous intent and previous state.
New state is a function of new intent and previous state. Formally, these are Mealy machines. Any leftover data from previous intents should be integrated into state. For the text-editor example, the editor state indicates which column the cursor should be on, and it may well be a behavior of the view alone which adjusts the cursor to be at the maximum column for short lines.
I started reading the post and making notes but I will not post any of that because in the end it turned out to be just a bad post. It promises to prove something but in my opinion even fails to clearly state the problem. It looks like a series of grumbles to justify a particular solution they used in their code. It might work sufficiently well for that particular codebase but doesn’t strike me as an exceptionally good universal solution.
The way I see it “Intent” is just “Invalid State”. Or “Intermediary State” if you will. And it’s true that it is much more prevalent on the front-end/UI side. OP can grumble about Stanly as much as they want but at some point you have to get a proper valid State. You have to resolve your merge conflicts in order to have a working (at least compiling/running) version of software. However unfinished your novel is it’s still saved in a valid document file. That intermediary state can be vast but it can’t be all the state. Once in a while it has to converge to a valid state. OP is discontent that system-level/back-end APIs accept only valid state but to me it looks more like a discontent that intermediary state is mostly concentrated in the front-end/UI. After all it’s easier to work with only valid state. The bigger portion of the application can work with valid-only state the simpler it is. I guess it would be fair to spread the misery across all the developer equally but I don’t see the benefits in spreading suffering. If anything the boundary of valid-only state should be pushed even further to the front-most edge of front-end/UI.
I’m not entirely sure what was the point of dunking on CRDTs. I guess it’s more complex than patch proposed by OP but last-write-wins will lose someone’s data and I don’t see how that’s a good thing.
User Intent as a first-class concept is a weird proposition. Intent is the desired final state that is not realised yet. Intent is always valid. No user ever wants an invalid state. As in the spreadsheet example: user’s intent is not to have circular dependencies between cells. It’s an intermediary state because user can not achieve what they want in a single operation. Intermediary state is not always invalid, either. Like in the CAD example: every door placement is valid (it’s snapped to a wall and isn’t blocked by anything) but not final as the user either can’t place the exact type of door at exact position, or hasn’t decided yet which one they want.
I largely agree with @pointlessone. This post is also just far too long. The git example seems inapplicable. And ultimately I feel like the solution being proposed is a slight specialisation of the command pattern, which was described like 40 years ago. And let’s talk about this bit:
I chose a text editor as an example because Stanley can’t dismiss this as just frivolous UI polish for limp wristed homosexuals. It’s essential that editors work like this.
Maybe I’d get more out of this article if it was arguing against a reasonable imaginary person instead of a parody. Or is there some cultural reference I’m missing that makes this less of a WTF?
I think Stanley is an obvious strawman. How otherwise Stanly can be reproached for his affinity for strongly typed languages while linking to a TypeScript codebase?
The author doesn’t really refute their strawman Stanley. The strawman’s attributes:
switch/caseis goodStanley ought to stop being a bigot, but otherwise seems like somebody whose experience has taught them that certain patterns are difficult to maintain over time. The author’s insight about intents is easy to merge with Stanley’s opinions: require intents to be statically typed and schematized, and suddenly there are no conflicts. For example, input devices have a finite collection of possible input messages which all derive from some schematic layout; input devices can be statically typed.
To be precise, this line is wrong:
New state is a function of new intent and previous state. Formally, these are Mealy machines. Any leftover data from previous intents should be integrated into state. For the text-editor example, the editor state indicates which column the cursor should be on, and it may well be a behavior of the view alone which adjusts the cursor to be at the maximum column for short lines.
I started reading the post and making notes but I will not post any of that because in the end it turned out to be just a bad post. It promises to prove something but in my opinion even fails to clearly state the problem. It looks like a series of grumbles to justify a particular solution they used in their code. It might work sufficiently well for that particular codebase but doesn’t strike me as an exceptionally good universal solution.
The way I see it “Intent” is just “Invalid State”. Or “Intermediary State” if you will. And it’s true that it is much more prevalent on the front-end/UI side. OP can grumble about Stanly as much as they want but at some point you have to get a proper valid State. You have to resolve your merge conflicts in order to have a working (at least compiling/running) version of software. However unfinished your novel is it’s still saved in a valid document file. That intermediary state can be vast but it can’t be all the state. Once in a while it has to converge to a valid state. OP is discontent that system-level/back-end APIs accept only valid state but to me it looks more like a discontent that intermediary state is mostly concentrated in the front-end/UI. After all it’s easier to work with only valid state. The bigger portion of the application can work with valid-only state the simpler it is. I guess it would be fair to spread the misery across all the developer equally but I don’t see the benefits in spreading suffering. If anything the boundary of valid-only state should be pushed even further to the front-most edge of front-end/UI.
I’m not entirely sure what was the point of dunking on CRDTs. I guess it’s more complex than
patchproposed by OP but last-write-wins will lose someone’s data and I don’t see how that’s a good thing.User Intent as a first-class concept is a weird proposition. Intent is the desired final state that is not realised yet. Intent is always valid. No user ever wants an invalid state. As in the spreadsheet example: user’s intent is not to have circular dependencies between cells. It’s an intermediary state because user can not achieve what they want in a single operation. Intermediary state is not always invalid, either. Like in the CAD example: every door placement is valid (it’s snapped to a wall and isn’t blocked by anything) but not final as the user either can’t place the exact type of door at exact position, or hasn’t decided yet which one they want.
I largely agree with @pointlessone. This post is also just far too long. The git example seems inapplicable. And ultimately I feel like the solution being proposed is a slight specialisation of the command pattern, which was described like 40 years ago. And let’s talk about this bit:
Maybe I’d get more out of this article if it was arguing against a reasonable imaginary person instead of a parody. Or is there some cultural reference I’m missing that makes this less of a WTF?
I think Stanley is an obvious strawman. How otherwise Stanly can be reproached for his affinity for strongly typed languages while linking to a TypeScript codebase?
[Comment removed by author]