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

Show HN: State Trooper – Tiny, no frills state machine for Go

github.com

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#31

Post by syngrog66 »

samsquire wrote: post #19
syngrog66 wrote: post #18

A state machine (specifically a FSM) class is something I end up having to reinvent in every new language I've adopted. Such a useful pattern whose need comes up repeatedly. Especially in games/sims or in anything with a GUI. Since I've been making both for decades I have a lot of homegrown FSM classes sitting around. :-p

I am working on a state machine formulation/notation that can be executed. The runtime is multithreaded and parallel. The idea is to execute the following state machine: thread(s) = fact(variable) | send(message) | receive(message2); thread(r) = fact(variable) | receive(message) | send(message2); This program waits until thread(s) is true in another thread until thread(r) is true, everything left of the equals symbol…

love it! shutup and take my money/adoption/usage/attention! ha

no but seriously, sounds like a good/useful plan/approach. please let me know if you share out a spec or impl sometime

BONUS points for a Golang or C lib

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#32

Post by rochak »

pjmlp wrote: post #20
bsaul wrote: post #17

enums with associated values (like in swift) really are the thing i miss the most in go.

Yeah, yet another Algol 60 missing feature. I really don't get how one can suggest the iota const dance with a straight face as an alternative.

The sooner you realise Go is just C with some niceties, the better.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#33

Post by packetslave »

earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

Commenters like you are why people don't share thing. Why make something available for free when someone like you is just going to come along and shit on it?

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#34

Post by BSEdlMMldESB »

earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

you mean like:

> Add valid transitions between states:

> `fsm.AddRule(CustomStateEnumA, CustomStateEnumB)`

> `fsm.AddRule(CustomStateEnumB, CustomStateEnumC)`

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#35

Post by pjmlp »

rochak wrote: post #32
pjmlp wrote: post #20

Earlier quoted context omitted.

Yeah, yet another Algol 60 missing feature. I really don't get how one can suggest the iota const dance with a straight face as an alternative.

The sooner you realise Go is just C with some niceties, the better.

When are C enumerations coming to Go?

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#36

Post by [deleted] »

packetslave wrote: post #33
earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

Commenters like you are why people don't share thing. Why make something available for free when someone like you is just going to come along and shit on it?

[deleted]

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#37

Post by syntheweave »

samsquire wrote: post #19
syngrog66 wrote: post #18

A state machine (specifically a FSM) class is something I end up having to reinvent in every new language I've adopted. Such a useful pattern whose need comes up repeatedly. Especially in games/sims or in anything with a GUI. Since I've been making both for decades I have a lot of homegrown FSM classes sitting around. :-p

I am working on a state machine formulation/notation that can be executed. The runtime is multithreaded and parallel. The idea is to execute the following state machine: thread(s) = fact(variable) | send(message) | receive(message2); thread(r) = fact(variable) | receive(message) | send(message2); This program waits until thread(s) is true in another thread until thread(r) is true, everything left of the equals symbol…

That is a description of flow-based programming, minus the generalization to "arbitrary packets of data in bounded buffers" - that is, your only data type is true/false and your only buffer size is 1, which lets you get some very clean syntax on it. It's a good invention!

FBP adapts the physical concept of unit record machines that operate over punchcard stacks, which predisposes it to thinking in terms of processing and transforming richer data like "characters in a string" or "records in an array", but it basically works for truth-signalling logic too - let truth packets wait in a buffer, and then when the node signals that the packets are able to move, that is the transition.

The emphasis does differ in that if we are thinking "FSM", the rest of the program and the data it handles have been abstracted, while if we are thinking "FBP" we're engaged with designing specific machines to connect together in terms of I/O, which is more helpful when you have a library of data operations to reuse.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#38

Post by klabb3 »

I saw the benchmark which seemed crazy (3us per transition and allocations). So looked quickly at the code.

Recommend putting the tracking of previous states in a separate optional debugging type so you don’t have to pay the cost in general. Oh and using time stamps as a key is kinda weird, but even weirder in Go where maps are non-deterministically enumerable.

Otherwise, seems like a good use of generics, given Golangs particular take on it.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#39

Post by akira2501 »

packetslave wrote: post #33
earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

Commenters like you are why people don't share thing. Why make something available for free when someone like you is just going to come along and shit on it?

If your only reasoning behind releasing an open source project is to receive uncritical accolades just for producing open source, then I think you need to examine your motives and seriously question why you expected this deference in the first place.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#40

Post by infogulch »

BSEdlMMldESB wrote: post #34
earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

you mean like: > Add valid transitions between states: > `fsm.AddRule(CustomStateEnumA, CustomStateEnumB)` > `fsm.AddRule(CustomStateEnumB, CustomStateEnumC)`

They should be named and other transitions disallowed.
Post reply on HN