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

Designing state machines

drivy.engineering

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Designing state machines

#41

Post by karboosx »

nerdponx wrote: post #34
karboosx wrote: post #10

Earlier quoted context omitted.

I didn't know GraphViz. I have to try it. DOT language looks very similar to Mermaid. It was too hard to make that compiler or you have encountered another problem?

I didn't even know what BNF was when I had the idea ;) It's still on my list of short projects. I have a lot of learning to do, knowing nothing about writing parsers and such. Yes, I know I could probably hack it together with a bunch of garbage Python. But that just does not sound fun to write, let alone maintain.

Apparently some people also wanted graphviz syntax: https://github.com/knsv/mermaid/issues/5

I also find another project called Viz.js[1]. It's graphviz in javascript. Looks promising. It's hard to choose between this two. On the one hand is very simple syntax, and on the other hand more flexibility.

[1] https://github.com/mdaines/viz.js/

Re: Designing state machines

#42

Post by troels »

When dealing with business processes, I feel that the evented nature of a formal fsm can be a bit off-putting. I have on several occasions used a batch-processing approach, that maintains state in a persistent record, giving many of the same characteristics as an fsm. Let's say we have our movie from the example (pseudo-code, obviously):

    class MovieState
This makes it very clear when things are happening. It's also easy to debug and test.

Of course, there are a lot of limitations, most notably that it can't deal with an async event happening. In my experience though, this can be dealt with by storing the payload of that event somewhere in the db, where the step-selector can access it on next run. One thing this model deals very well with, is delays, which is often part of business processes.

Any thoughts? Does this design have a more formal name?

Re: Designing state machines

#43

Post by Dowwie »

pwm wrote: post #12

I have recently created some dead simple code to explain the concept to colleagues whom, as the article notes, were not using this very simple and effective construct at all to control state transitions in business apps. As the article does not really explain how state machines work let me try to do it here so maybe you will go back to your code and put one in place :) In general, if anywhere in your code you have so…

Well done. The puml script was a nice addition!

Re: Designing state machines

#44

Post by bushin »

troels wrote: post #42

When dealing with business processes, I feel that the evented nature of a formal fsm can be a bit off-putting. I have on several occasions used a batch-processing approach, that maintains state in a persistent record, giving many of the same characteristics as an fsm. Let's say we have our movie from the example (pseudo-code, obviously): class MovieState This makes it very clear when things are happening. It's also e…

Looks like an event loop.

Re: Designing state machines

#45

Post by vanderZwan »

idbfs wrote: post #36

A paper that changed my approach to designing state machines is "Statecharts: A Visual Formalism for Complex Systems" by Harel ( http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.p... ). Statecharts (also called hierarchical state machines) are essentially generalized state machines which allow for nesting and parallel composition of states. The 'nesting' part is my favourite, since it allows one to delegate…

Funny how most visual programming languages (for example, puredata) look like these diagrams.

Re: Designing state machines

#46

Post by jbritton »

I typically try to avoid state machines. I like to have a function like model = reduce(model, event) where model is an environment of variable:value bindings. This function then just uses (if expr/else if expr) to find a condition in which to process the event. Processing the event involves changing the values in the model environment. I suppose on some level the two approaches are the same, but they feel and look different to me. If the "if/else if" pattern is deeply nested, then this is kind of like traversing a state machine to reach the correct state for processing the event. So in this case maybe a state machine is more efficient. However, a state machine, involves a history. You really need an external diagram. You need to see how you get to a state and how you transition out of a state. An "if/else if" type approach puts all the decision making in the code right in front of me. I don't need a diagram. The "if/else if" approach is often much more concise as the expressions are a powerful modeling approach. Finally, I prefer to avoid deeply nested if/else if" conditions, because it can be a chore to traverse the tree and really understand the path taken to get to the event handling spot. If the conditions can be written as linear list of rules where each rule can be thought about in isolation, I find this easier. This often involves repeating test conditions. Just flatten the decision tree by repeating the preconditions. This is again less efficient, but if you save the results of the expression computations then it becomes a simple test of Boolean values. I like to think of this approach as a rules engine instead of a state machine. A state machine encodes information in the state diagram so that it doesn't need to be stored in variables. The rules engine encodes all the knowledge in variables and rules.

Re: Designing state machines

#47

Post by rebootthesystem »

activatedgeek wrote: post #22

While I understand the importance of state machines and its direct usage in complex Business Logic Workflows (and indirectly almost everywhere), there is nothing special in this post. It is a generic comment on State Machines. Am I missing something here?

I am always surprised to see how many software developers I come across who have no experience whatsoever applying FSM's in the course of their work.

I can unequivocally say that FSM's have made me tons of money. By that I mean that they have simplified projects, made them far more robust, easily extensible, simple to modify and, in general terms, quicker to develop with less bugs and errors.

I've used FSM's in FPGA's (for example, optimized DDR memory controllers), embedded projects, robotics and system software. In other words, everywhere.

Re: Designing state machines

#48

Post by rebootthesystem »

jbritton wrote: post #46

I typically try to avoid state machines. I like to have a function like model = reduce(model, event) where model is an environment of variable:value bindings. This function then just uses (if expr/else if expr) to find a condition in which to process the event. Processing the event involves changing the values in the model environment. I suppose on some level the two approaches are the same, but they feel and look di…

You might want to read-up on table driven state machines. I'm not sure you have a full view of what's possible.

Re: Designing state machines

#49

Post by rebootthesystem »

troels wrote: post #42

When dealing with business processes, I feel that the evented nature of a formal fsm can be a bit off-putting. I have on several occasions used a batch-processing approach, that maintains state in a persistent record, giving many of the same characteristics as an fsm. Let's say we have our movie from the example (pseudo-code, obviously): class MovieState This makes it very clear when things are happening. It's also e…

That's the problem with kids these days. Everything has to be a friggin class.

You know we did some pretty amazing things with computers before OO. We even landed people on the Moon.

Can anyone program without OO any more?

Just saying.

Re: Designing state machines

#50

Post by troels »

rebootthesystem wrote: post #49
troels wrote: post #42

When dealing with business processes, I feel that the evented nature of a formal fsm can be a bit off-putting. I have on several occasions used a batch-processing approach, that maintains state in a persistent record, giving many of the same characteristics as an fsm. Let's say we have our movie from the example (pseudo-code, obviously): class MovieState This makes it very clear when things are happening. It's also e…

That's the problem with kids these days. Everything has to be a friggin class. You know we did some pretty amazing things with computers before OO. We even landed people on the Moon. Can anyone program without OO any more? Just saying.

I recognise that your tongue and cheek may be in close proximity here, but care to elaborate?
Post reply on HN