Programmers are bad at managing state when they forget to use the tools made for managing state. I've had to work on code bases where the state was "implicit" and encoded in a bunch of different fields which "grew" over time and it's a full on nightmare. Even a rudimentary state machine which makes both application state and transitions between states explicit feels like a super power by comparison.
Programmers are bad at managing state (2020)
21–30 of 60 posts
Re: Programmers are bad at managing state (2020)
#22We actually have a great tool to manage state, but nobody seems to have used it to its full potential: regular expressions. Imagine your program is a big state machine, and inputs and other events are making it transition from one state to another, and when in a state the apropos actions are performed. On this view, your program just is a regular expression parser--the tokenized stream of input events is what it is p…
Well, actually, you store your part of your state in a theoretically unbounded random access memory device, or equivalently, a tape.
Re: Programmers are bad at managing state (2020)
#23Popped in here to say that AFAIK/IMO, most of the things people treat as "state" is actually "data". And then I started thinking myself in circles around "okay, so what is state?". Rather than /keep/ thinking myself in circles, I'll ask: What do y'all think "state" is ?
State is data that you use in control flow decisions.
(This is a 5-second reaction, not a deeply considered opinion, don't take it too seriously)
Re: Programmers are bad at managing state (2020)
#24Programmers are bad at managing state when they forget to use the tools made for managing state. I've had to work on code bases where the state was "implicit" and encoded in a bunch of different fields which "grew" over time and it's a full on nightmare. Even a rudimentary state machine which makes both application state and transitions between states explicit feels like a super power by comparison.
What tool do you recommend to do so?
Re: Programmers are bad at managing state (2020)
#25Programmers are bad at managing state when they forget to use the tools made for managing state. I've had to work on code bases where the state was "implicit" and encoded in a bunch of different fields which "grew" over time and it's a full on nightmare. Even a rudimentary state machine which makes both application state and transitions between states explicit feels like a super power by comparison.
What tool do you recommend to do so?
Sum type is key, called "discriminated union" sometimes generally. In Rust this is an `enum`. Simulated in some languages as tuples with tag first element. Discrete number of states, attaching information only relevant to each single state. Thus, never have invalid combination of other fields.
Re: Programmers are bad at managing state (2020)
#26Re: Programmers are bad at managing state (2020)
#27Earlier quoted context omitted.
What tool do you recommend to do so?
Sum type is key, called "discriminated union" sometimes generally. In Rust this is an `enum`. Simulated in some languages as tuples with tag first element. Discrete number of states, attaching information only relevant to each single state. Thus, never have invalid combination of other fields.
I think in this context 'state' means 'state which changes over time', not necessarily the shape of the state at rest.
Turning it off and on again will fix mutable state, not poorly-typed state.
Re: Programmers are bad at managing state (2020)
#28Programmers are bad at managing state when they forget to use the tools made for managing state. I've had to work on code bases where the state was "implicit" and encoded in a bunch of different fields which "grew" over time and it's a full on nightmare. Even a rudimentary state machine which makes both application state and transitions between states explicit feels like a super power by comparison.
Classic state management must be taught and learned to understand the why of current state management solutions and why so many come and go.
Re: Programmers are bad at managing state (2020)
#29Programmers are bad at managing state when they forget to use the tools made for managing state. I've had to work on code bases where the state was "implicit" and encoded in a bunch of different fields which "grew" over time and it's a full on nightmare. Even a rudimentary state machine which makes both application state and transitions between states explicit feels like a super power by comparison.
What tool do you recommend to do so?
Just look for state-machine (finite state automata) on github
https://github.com/search?q=state-machine&type=repositories
This is a very common pattern in Ruby to manage state. It's especially useful to guard entering impossible states with respect to business logic and figuring out what went wrong. Something along the lines of:
Can't transition Command from 'ordered' to 'to-deliver': paid() == false
Re: Programmers are bad at managing state (2020)
#30We actually have a great tool to manage state, but nobody seems to have used it to its full potential: regular expressions. Imagine your program is a big state machine, and inputs and other events are making it transition from one state to another, and when in a state the apropos actions are performed. On this view, your program just is a regular expression parser--the tokenized stream of input events is what it is p…
Well, actually, you store your part of your state in a theoretically unbounded random access memory device, or equivalently, a tape.
Yeah, but what if we didn't do that? I.e. when we are reading from memory, we treat it as part of the tokenized input stream, and whatever we are writing to memory is just the transformed output of the state machine.
This way, the contents of the memory wouldn't be state at all; they would just be, as it were, the scratchpad where sentences in the language accepted by the state machine, or output by the state machine, are found.
That's what regular expressions do for us: they are a compact way of specifying a language. Just a few characters--which is to say, just a few states--can specify a language which contains arbitrarily long strings.
But--even though the input and output streams can be very large, they no longer part of the state, and thus do not contribute to the exponential blowup of states.