Better question: Why do we endlessly produce so much state?
Can you elaborate on your argument? Otherwise, it's a stupid question.
Why developers never use state machines (2011)
111–120 of 121 posts
Re: Why developers never use state machines (2011)
#112Better question: Why do we endlessly produce so much state?
Huh? Computation can't happen without state. Everything you make has a state, otherwise it won't really do anything interesting.
Balance in all things
Edit: eh, that comment didn’t really say much. What I meant was that there are classes of algorithms that are stateless. Maybe the most useful are proofs.
Look, I’m a C++ dev. I live and breathe state. Weird, mostly-working gadgets are the real humans of the world.
But that doesn’t mean I don’t use linear types and write unit tests for my function composition. Sure, I’ll let closures capture their context, and I’ll allow pass-by-reference in my APIs, but that doesn’t mean I encourage it.
Re: Why developers never use state machines (2011)
#113Better question: Why do we endlessly produce so much state?
Can you elaborate on your argument? Otherwise, it's a stupid question.
The argument is that we don’t compose enough functions to create value. Instead, we lean on (not always well defined) state, the result of operations on data
Re: Why developers never use state machines (2011)
#114Earlier quoted context omitted.
Huh? Computation can't happen without state. Everything you make has a state, otherwise it won't really do anything interesting.
Balance in all things Edit: eh, that comment didn’t really say much. What I meant was that there are classes of algorithms that are stateless. Maybe the most useful are proofs. Look, I’m a C++ dev. I live and breathe state. Weird, mostly-working gadgets are the real humans of the world. But that doesn’t mean I don’t use linear types and write unit tests for my function composition. Sure, I’ll let closures capture the…
> What I meant was that there are classes of algorithms that are stateless.
Can you give me an example?
Re: Why developers never use state machines (2011)
#115Earlier quoted context omitted.
Balance in all things Edit: eh, that comment didn’t really say much. What I meant was that there are classes of algorithms that are stateless. Maybe the most useful are proofs. Look, I’m a C++ dev. I live and breathe state. Weird, mostly-working gadgets are the real humans of the world. But that doesn’t mean I don’t use linear types and write unit tests for my function composition. Sure, I’ll let closures capture the…
> What I meant was that there are classes of algorithms that are stateless. Can you give me an example?
Practically speaking, any algorithm that does the same thing given the same input is said to be stateless.
This property becomes more useful when you’re trying to prove something about a function’s behavior over a bunch of well-defined types.
Languages like Haskell and Agda have these properties.
Rust also has some of these properties by default. It has an affine type system (the borrow checker) enforces some guardrails on ad-hoc state manipulation. C++ has linear-esque types in its pointers and higher-kinded types in the concepts and constraints features.
Re: Why developers never use state machines (2011)
#116Earlier quoted context omitted.
> What I meant was that there are classes of algorithms that are stateless. Can you give me an example?
Practically speaking, any algorithm that does the same thing given the same input is said to be stateless. This property becomes more useful when you’re trying to prove something about a function’s behavior over a bunch of well-defined types. Languages like Haskell and Agda have these properties. Rust also has some of these properties by default. It has an affine type system (the borrow checker) enforces some guardra…
This is kind of nitpicky, but I'll say it anyway.
An algorithm that does the same thing given the same input is deterministic aka referentially transparent aka pure, not stateless.
Even this little snippet of Haskell is stateful:
statefulFunction :: Int -> Int
statefulFunction x =
let y = x * x
y + y
People seem to use "stateless" as a word for "doesn't mutate anything", which is kind of weird. Mutability has _nothing_ to do with having state.
Re: Why developers never use state machines (2011)
#117Earlier quoted context omitted.
Practically speaking, any algorithm that does the same thing given the same input is said to be stateless. This property becomes more useful when you’re trying to prove something about a function’s behavior over a bunch of well-defined types. Languages like Haskell and Agda have these properties. Rust also has some of these properties by default. It has an affine type system (the borrow checker) enforces some guardra…
This is kind of nitpicky, but I'll say it anyway. An algorithm that does the same thing given the same input is deterministic aka referentially transparent aka pure, not stateless. Even this little snippet of Haskell is stateful: statefulFunction :: Int -> Int statefulFunction x = let y = x * x y + y The binding 'y' is state. Even if it's implicit, as in ((x * x) + (x * x)), it's still state. People seem to use "stat…
Algorithms != computation
Re: Why developers never use state machines (2011)
#118Earlier quoted context omitted.
This is kind of nitpicky, but I'll say it anyway. An algorithm that does the same thing given the same input is deterministic aka referentially transparent aka pure, not stateless. Even this little snippet of Haskell is stateful: statefulFunction :: Int -> Int statefulFunction x = let y = x * x y + y The binding 'y' is state. Even if it's implicit, as in ((x * x) + (x * x)), it's still state. People seem to use "stat…
Algorithms != computation
Then no algorithm holds state, because an algorithm is just a ruleset.
Re: Why developers never use state machines (2011)
#119As a regular user of the state_machine Ruby gem, I wouldn't recommend it. If you don't believe me, just check out the "Class definition" section of the usage examples: https://github.com/state-machines/state_machines#usage The problems are obvious. It's built on magic and indirection. This leads to difficult to debug state machine problems. For anything beyond simple state machines you quickly lose any idea of what y…
I’d strongly recommend Statesman instead: https://gocardless.com/blog/statesman/ I’m unaffiliated, just have used a lot of Ruby SM libraries.
Looks just as bad tbh, mixins and magic, I don't think you can really do this well in Ruby.
Re: Why developers never use state machines (2011)
#120I'm an EEE, and one of the strange things I've noticed is that, for whatever reason, people from a CompSci background is really, really have trouble building and understanding even simple state machines. I suspect this unintuitiveness is the main reason why we don't see more state machines, as even in the case where they're an optimal solution many SWEs will shy away from them. Locally-rendered UIs are probably one o…
I was trained as an EE and occasionally use a state machine in my code. Every other time I've encountered a state machine it was also written by someone trained as an electrical engineer or similar.
I tend to use them a lot when dealing with hardware (I'm an embedded software dev, so that happens reasonably often). Most hardware devices have some sort of state machine you need to keep track of. So hardware drivers tend to model the state machine, to track what the hardware is doing.