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

Buttons as Finite Automata

web.stanford.edu

Post reply on HN
Print view View original

61–70 of 82 posts

Re: Buttons as Finite Automata

#61

Post by ynx »

caseyross wrote: post #55

What's also interesting to realize is that the standard HTML button is a sort of unholy chimera that doesn't model any sort of physical button in common usage. Physically speaking, we generally have either: 1. a "push" button, which activates when you press it down fully, or 2. a "hold" button, which activates continuously when you hold it down. In either case, the "action" occurs at the instant you press the button…

To be fair, it's not just HTML, "Touch Up Inside" is the usual button press event to subscribe to on iOS/macOS, and to my personal knowledge this has been true on iOS from day 1 (unsure about macOS or at least NeXTSTeP), so there is an argument that it is at least somewhat normalized, though your point about it not matching up with most IRL buttons makes sense.

However it's also worth noting that IRL buttons tend to require more than a feather's touch to detect a press, whereas there is no such margin on monitors/pointing devices.

Re: Buttons as Finite Automata

#64

Post by ggm »

atoav wrote: post #43
zevv wrote: post #18

I am an embedded software engineer, and I love everything about this FSM example. It shows that seemingly simple and binary things often have more complexity then meets the eye. I love using old fashioned finite state machines for implementing all kinds of behavior; if forces you to think about every single state and transition, and it naturally isolates the different cases - basically, it makes it easier to think an…

You: "So you want action A to happen immediately when the button is pushed AND 3 seconds after that when the button is still held action B should happen?" Customer: "No, I only want action B when it is held for 3 seconds" You: "Todays technology can't do that" Customer: "What. Wait. Why?" You: "Because at the point when action A would be triggered we would have to know the future to tell whether the button will have…

Lie about immediate effect, wait 1.5sec on press A. If it was It depends on the lie, but I think it probably fits human-centric timescale.

The alternative is to work on the partially ordered set of events {A, B, undo-A} and convert to {A, undo-A}, {B} and then transform to {no-op, B}

Hysteresis/Queue is your friend.

Re: Buttons as Finite Automata

#65

Post by awinter-py »

uhhh 'spinner' state pls?

lack of loading state in buttons is a huge unforced error that makes all ajax stuff way more verbose than it has to be

the dom has no idea of how client-server applications work, which is defensible because the dom is so old but doesn't portend well for either 1) the quality of the google-weighted standards process or 2) the future of the web as the platform for saas and non-mobile consumer

Re: Buttons as Finite Automata

#67

Post by NoWizards »

zevv wrote: post #18

I am an embedded software engineer, and I love everything about this FSM example. It shows that seemingly simple and binary things often have more complexity then meets the eye. I love using old fashioned finite state machines for implementing all kinds of behavior; if forces you to think about every single state and transition, and it naturally isolates the different cases - basically, it makes it easier to think an…

Is there a (mathematical if possible) way, using FSMs, to demonstrate if a specific case or behavior can or can't be implemented.

Re: Buttons as Finite Automata

#68

Post by glitchc »

NoWizards wrote: post #67
zevv wrote: post #18

I am an embedded software engineer, and I love everything about this FSM example. It shows that seemingly simple and binary things often have more complexity then meets the eye. I love using old fashioned finite state machines for implementing all kinds of behavior; if forces you to think about every single state and transition, and it naturally isolates the different cases - basically, it makes it easier to think an…

Is there a (mathematical if possible) way, using FSMs, to demonstrate if a specific case or behavior can or can't be implemented.

Yes there is. You may want to look into Deterministic and Non-Deterministic Finite Automata. They are foundational to computability and Turing machines.

https://en.wikipedia.org/wiki/Deterministic_finite_automaton...

Re: Buttons as Finite Automata

#69

Post by ThinBold »

NoWizards wrote: post #67
zevv wrote: post #18

I am an embedded software engineer, and I love everything about this FSM example. It shows that seemingly simple and binary things often have more complexity then meets the eye. I love using old fashioned finite state machines for implementing all kinds of behavior; if forces you to think about every single state and transition, and it naturally isolates the different cases - basically, it makes it easier to think an…

Is there a (mathematical if possible) way, using FSMs, to demonstrate if a specific case or behavior can or can't be implemented.

You are designing a "prefix code". It is a collection of strings of button presses such as {A, BA, BBAA, BBABA, BBB, ...}. Each string maps to an action.

Ideally no string is a prefix of another string. Even more ideally any infinite sequence of As and Bs can be decoded into a sequence of actions.

Re: Buttons as Finite Automata

#70

Post by thaumasiotes »

zevv wrote: post #18

I am an embedded software engineer, and I love everything about this FSM example. It shows that seemingly simple and binary things often have more complexity then meets the eye. I love using old fashioned finite state machines for implementing all kinds of behavior; if forces you to think about every single state and transition, and it naturally isolates the different cases - basically, it makes it easier to think an…

> "Oh, so you mean, perform action A when the button us released within 3 seconds?". "Well, no I want it do A when I push the button".

It seems like what's gone wrong here is not that the customer wants something impossible, but that they don't understand what you mean when you say "perform action A when the button is released".

If you show one of those people a device with the behavior you describe -- e.g. "toggle a light if the button is released within 0.5 seconds, but toggle the other light, instead, if it's pressed and held for 3 seconds" -- would they agree that it does what they say they want?

Almost everyone understands "pushing a button" to include the action of releasing the button.

Post reply on HN