I have a question for the author or anyone smart enough to understand the whole post:
what's the difference here between state and data? Isn't data more generic, and we can have the title 'make invalid data unrepresentable'?
Because I have this instinct to do what I call in my mind and to my friend 'ddd', for 'data driven programming'. It translate by first thinking on my global inputs, outputs, and transformations, then writing the data structure (I learned with C), then prototyping the core functions (basically I write the .h before the .c).
Is it the same thing? Let the data write the code (or state, and they're the same thing here?) or did I miss something important?
Do you think "state machines" should be called "data machines"? Why or why not?
IMO "state" is a better fit for the concept that this is getting at. The point is to stop the program getting into an invalid state, not to stop the program operating on invalid data, because a program might need to process data that's invalid in some sense, and because the program state is something a bit more active than "data" (e.g. having the right data at the wrong stage of execution is also an invalid state, even though it isn't exactly "invalid data").
Very insightful (you and your siblings), thank you all. I think I have a fundamental misunderstanding of what a state is, maybe because I mostly practice responding to external state changes? I don't know, I'll think on that. Thank you again.
The way I understand it, "state" refers to any point in time during the execution of a program.
A computer program can be split into 3 large parts: input, process, output. And invalid data, in my opinion, only concerns the first part, whereas invalid states can be found throughout all parts of the program due to e.g. bugs.
That makes "make invalid states unrepresentable" more generic than "make invalid data unrepresentable". Or to put it in another way: invalid data can lead to invalid states, but not all invalid states are due to invalid data.
"State" alludes to "state machine". It's natural to refer to inputs and outputs as "data", and they are definitely not "state", but the thing in the middle while processing the data? That's state, including things like the file pointer and the lexer state machine which are not part of the "data".
what's the difference here between state and data? Isn't data more generic, and we can have the title 'make invalid data unrepresentable'?
Because I have this instinct to do what I call in my mind and to my friend 'ddd', for 'data driven programming'. It translate by first thinking on my global inputs, outputs, and transformations, then writing the data structure (I learned with C), then prototyping the core functions (basically I write the .h before the .c).
Is it the same thing? Let the data write the code (or state, and they're the same thing here?) or did I miss something important?