There are nuances to this, too, though: You can be communicating
> I think the thing is simple, that the details are unimportant (to me, to us)
…and simply be ignorant of a lot of the details that make this not simple for the person who has to "just".
I had such a "discussion" with someone who did exactly this and then refused to even acknowledge there are technical details in their "just" and that their "just" involves multiple wasted person days of effort (in this case for little benefit, as their "just" was to paint over them having to do something themselves). It's infuriating.
Now, the "just" isn't the only part of the problem here, but it will most likely the part where any useful discussion breaks down.
And, while I can blame my encounter on a person with… problematic particularities, it isn't obvious to me that one would always be able to discern easily if one is walking into the same trap.
Both programmed with a slightly adapted US layout and ESC instead of caps lock. Plus I have "hold down ESC" as a layer for very primitive vim binding simulation for Windows (e.g. mapping hjkl to arrow keys or b to ctrl-left and e and w to ctrl-right).
Which is exactly what happened to the first "dictator for life" (without the B) ;-). Even at more or less the exact age where one would expect someone to retire today.
See also: Julius Caesar, Ides of March
Edit: Just to make this clear, I also find the "I'm doing this as long as it works out and makes sense" to be the only useful approach to the "title" of BDFL.
Meh, you can easily twist that into a bad policy, too (and yes, people do that). At work, some of my colleagues litter many repos (I don't usually have to work with, thankfully) with dozens of commits having the same ticket ID and the title of the ticket as their subject. Usually pushed straight to trunk (full of foxtrot merges if two people work at the same time). And in the message body, then, there's usually the unhelpful "fix typo".
My opinion: Write readable messages, scope your commits to simple changes, put them on a branch, use `--autosquash`, put the ticket ID in the merge commit's message. It really isn't hard.
State is the data required to continue the operation of a program. That's always the case (also in non-FP contexts), but state is often smeared all over a program as only loosely and implicitly connected pieces whereas FP is mainly concerned with how to manage state (and thus also with how to compose such pieces of state into a greater whole so it's easier to manage).
Edit: Note that there is also "data you don't need for continuing the operation of the program", which we could categorize as "input", "output" and "wasted memory/storage/cpu cycles". The last of the three can obviously still be crucial for other reasons than program execution (e.g. debugging), which makes the line between output and waste blurry.
I like it! I don't know if I agree, but, the category of "data required to continue the operation of the program" is a pretty excellent category, thank you for pointing it out!
Maybe... As you say, state is the information required for continued execution. Which would make "data" the information that's carried through the program. Like - parts of an HTTP request are "state" because they're what you use to route the packet through the internet. The other parts are "data", because all the intermediate programs don't use it during their operation; it's just passed through.
