Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why developers never use state machines (2011)

skorks.com

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Why developers never use state machines (2011)

#61

Post by Multicomp »

KRAKRISMOTT wrote: post #13
AussieWog93 wrote: post #8

I'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…

They do not scale well. It is why Elm-style explicit message passing UIs are not popular. State machines work for state localised to a widget, but the moment you scale up to something moderately complex (spreadsheets, datagrids, forms etc.), your diagrams balloons in size. For non safety-critical applications, it is better to have implicit state and potential bugs than to have your engineering team waste time proving…

> but the moment you scale up to something moderately complex (spreadsheets, datagrids, forms etc.), your diagrams balloons in size

I'm no CS major. But isn't that what Hierarchical state machines are supposed handle? Or was that all hat no cattle and/or a lost knowledge when UML style stuff got tossed away?

Re: Why developers never use state machines (2011)

#62

Post by wyldfire »

Any discussion of "state machines" is not complete without a mention of Statecharts (or Harel Statecharts) [1] [2] [3]. The hierarchy and triggered actions are a really excellent way of representing a state machine.

[1] https://en.wikipedia.org/wiki/State_diagram#Harel_statechart

[2] https://statecharts.dev/

[3] https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts....

Re: Why developers never use state machines (2011)

#63

Post by jjtheblunt »

lmm wrote: post #54
jjtheblunt wrote: post #51

Earlier quoted context omitted.

Those regexes that are ubiquitous are called regular expressions because they describe “regular languages” (qv), which are recognized by nondeterministic finite automata, which are converted to deterministic finite automata by fun with powersets, which are compiled into software state machines behind the abstraction of the regex libraries. So they are not at all rare but not exposed to programmers explicitly.

Almost all "regexes" in programming languages are not actually regular expressions and do not have the properties you describe. (I'd argue that this is one of the clearest demonstrations that programmers do not put a lot of value of state machines)

Yes definitely a different thing when talking about ‘extended regex’ libraries, wrt to the regular languages (language class) and associates recognizers.

That said, even modern pcre uses state machines

https://github.com/rurban/pcre/blob/master/src/pcre2_dfa_mat...

Re: Why developers never use state machines (2011)

#64

Post by eyelidlessness »

Joel_Mckay wrote: post #37
eyelidlessness wrote: post #31

Earlier quoted context omitted.

> Most people attempt to achieve Idempotence whenever possible, and there are several reasons this is desirable in HA systems. Fundamentally, the REST paradigm broke peoples brains, and set many projects on a doomed trajectory into the sun. Respectfully… wha?

If you have under 40k users, than you can get away with a lot of bad choices. =)

Sure, I’m just trying to understand the thing you previously said.

Re: Why developers never use state machines (2011)

#65

Post by kaba0 »

e-dant wrote: post #48

Woah — with all the declarative and functional languages, looks like someone has just discovered a (stateful) state machine. They’re trying to convince us that this is a useful thing in a hypothetical situation where people do ridiculous, unsafe things on an ad-hoc basis. Not sure I’m buying it. Oh, wrong universe. Edit: I use state, too. I get it. I just dislike it. It doesn’t usually compose and is rarely safe.

It is not hard to argue that several FP abstractions are basically state machines themselves, their transition function is simply recursively defined.

For a trivial example, objects defining the Applicable trait.

Re: Why developers never use state machines (2011)

#66

Post by spc476 »

AussieWog93 wrote: post #8

I'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…

Here's a real-world example from my previous job. A process makes two simultaneous requests (we're on a tight dead line here). Here is the enumerated states we have to code for:

    send 1,2 -> receive 1, receive 2, process
    send 1,2 -> receive 2, receive 1, process
    send 1,2 -> receive 1, timeout 2, process, receive 2 (which is ignored)
    send 1,2 -> receive 1, timeout 2, process (2 is lost)
    send 1,2 -> receive 2, timeout 1, process, receive 1 (which is ignored)
    send 1,2 -> receive 2, timeout 1, process (1 is lost)
    send 1,2 -> timeout 1,2, process, receive 1,2 (which are ignored)
    send 1,2 -> timeout 1,2, process, receive 2,1 (which are ignored)
    send 1,2 -> timeout 1,2, process, receive 1 (which is ignored; 2 is lost)
    send 1,2 -> timeout 1,2, process, receive 2 (which is ignored; 1 is lost)
    send 1,2 -> timeout 1,2, process (1,2 are lost)
You might think that after the process step, we can ignore anything we receive, but we need to make sure we ignore the timed out replies, because this "state machine" is running a few dozen/hundred times a second, depending upon load.

As I was leaving, there was talk of making a third concurrent request. States start exploding here. Maybe if there were languages that made this easy to implement they would be used more often (the code in question was in a mixture of C89/C++98).

Re: Why developers never use state machines (2011)

#67

Post by moloch-hai »

This is a strange take. Every last program ever written is a state machine.

The number of possible states a program represents is normally very, very large, and the transition rules are very complicated and often mixed up with, e.g., multiplier circuits. So we use familiar programming languages instead, which help to organize it all. A program emulating another state machine tends to raise the question why the (or anyway some) programming language is not being used to manage its complexity.

So in practice we emulate only the simplest of state machines explicitly. A programmer writing such a program is sometimes said to be in a state of sin.

Re: Why developers never use state machines (2011)

#68

Post by e-dant »

kaba0 wrote: post #65
e-dant wrote: post #48

Woah — with all the declarative and functional languages, looks like someone has just discovered a (stateful) state machine. They’re trying to convince us that this is a useful thing in a hypothetical situation where people do ridiculous, unsafe things on an ad-hoc basis. Not sure I’m buying it. Oh, wrong universe. Edit: I use state, too. I get it. I just dislike it. It doesn’t usually compose and is rarely safe.

It is not hard to argue that several FP abstractions are basically state machines themselves, their transition function is simply recursively defined. For a trivial example, objects defining the Applicable trait.

Which abstractions?

I could see a monad being defined as a list of (typed) states with a functor. But they’re still stateless.

I could also see immutable data structures being implemented in a stateful way (they usually are in non-FP languages).

Re: Why developers never use state machines (2011)

#69

Post by dang »

Related:

Why Developers Never Use State Machines - https://news.ycombinator.com/item?id=20875583 - Sept 2019 (1 comment)

Why Developers Never Use State Machines (2011) - https://news.ycombinator.com/item?id=16470262 - Feb 2018 (161 comments)

Why Developers Never Use State Machines (2011) - https://news.ycombinator.com/item?id=12204038 - Aug 2016 (1 comment)

Why Developers Never Use State Machines - https://news.ycombinator.com/item?id=2949543 - Sept 2011 (92 comments)

Re: Why developers never use state machines (2011)

#70

Post by [deleted] »

e-dant wrote: post #68
kaba0 wrote: post #65

Earlier quoted context omitted.

It is not hard to argue that several FP abstractions are basically state machines themselves, their transition function is simply recursively defined. For a trivial example, objects defining the Applicable trait.

Which abstractions? I could see a monad being defined as a list of (typed) states with a functor. But they’re still stateless. I could also see immutable data structures being implemented in a stateful way (they usually are in non-FP languages).

[deleted]
Post reply on HN