Live data from Hacker News

Buttons as Finite Automata

web.stanford.edu

71–80 of 82 posts

Re: Buttons as Finite Automata

#71
post #27

What I love about this is back in the archaic days when car radios had (mechanical) radio buttons, that was the introductory example of a tiny state machine. They were also used in other devices but the car radio was the application everybody had seen. Nowadays I imagine only a small proportion of people who deploy "radio buttons" have even seen such a car radio, so the metaphor is now empty, like the floppy disk ico…

Huh. I never understood the terminology "radio button", and I have no memory of noticing such a thing in a car. But it could easily have been there; why would I have cared?

I did have a tape player with buttons (play / rewind / stop / etc) that, when pushed, unpushed the other buttons. So I have a mental model for buttons of that kind. But I've never associated them with a radio.

Also, I've never associated the radio selector HTML element with a button (HTML or otherwise). Buttons are about triggering effects. But radio selectors are about selecting something; they have more in common with checkboxes.

Re: Buttons as Finite Automata

#72
Also shows one of the fun aspects of many finite automata I encounter...

If you right click it, it gets stuck thinking it's "pressed" until you click somewhere.

As much as I like FSM in principle, I feel like substantially more than half that I've encountered in software have either failed to accurately model how a system actually behaves, or have been missing core states that are a natural fit for real-world use. It has grown to become a fairly accurate predictor for me that a system is going to have problems due to over-simplification and lack of flexibility.

Which is not a FSM problem obviously, but the correlation is astoundingly strong. I'm not sure why. They obviously work out fine in many places. Maybe software uses I've run across are just way more complicated than can be accurately understood from a visual diagram? This one certainly seems reasonable and complete, yet...

Re: Buttons as Finite Automata

#73
post #46

Earlier quoted context omitted.

PM: "Let's not rush into any hasty answers!" (Under no circumstances should you show them this: https://www.youtube.com/watch?v=BKorP55Aqvg )

This is entertaining, but also cringe; clients and product people aren't generally idiots. They just have requirements that they can't adequately express. Requirements capture is part of every eng job I've had.

They aren't generally idiots but sometimes their mental model of the problem space is incomplete and they don't understand what they're asking for. This is fine if they don't want to specify details. However when they do it can result in impossible requests.

Re: Buttons as Finite Automata

#74

Earlier quoted context omitted.

Safari on a mac. The context menu pulls up, but even when dismissed, it's still stuck in the "idle, down" state.

Repro's on Chrome/Mac as well--I think it's a macOS issue.

Not sure why it seems MacOS related, but same thing here on mac (safari and firefox).

I added a `#button:active` style to see if it was actually leaving it activated after dismissing the context menu, but apparently no. Not sure what the cause is.

Re: Buttons as Finite Automata

#75
The Elm architecture feels like you're making little state machines for your UI. It's a really nice way of doing things.

Note: I've not actually tried Elm only Elmish in F#.

Re: Buttons as Finite Automata

#76
post #3

This is something I created many, many years back for Stanford’s CS103 course as a lecture demo. Apologies for the lack of mobile support - I’ve always presented this from my laptop. :-)

Just wanted to say thank you so much for your incredible lectures! - A random student who took CS103 with you in Fall 2019

Re: Buttons as Finite Automata

#77
post #27

What I love about this is back in the archaic days when car radios had (mechanical) radio buttons, that was the introductory example of a tiny state machine. They were also used in other devices but the car radio was the application everybody had seen. Nowadays I imagine only a small proportion of people who deploy "radio buttons" have even seen such a car radio, so the metaphor is now empty, like the floppy disk ico…

Huh. I never understood the terminology "radio button", and I have no memory of noticing such a thing in a car. But it could easily have been there; why would I have cared? I did have a tape player with buttons (play / rewind / stop / etc) that, when pushed, unpushed the other buttons. So I have a mental model for buttons of that kind. But I've never associated them with a radio. Also, I've never associated the radio…

I vaguely remember when I was a kid our hifi system had buttons like that, they were all round cylindrical buttons

Re: Buttons as Finite Automata

#78
post #46

Earlier quoted context omitted.

PM: "Let's not rush into any hasty answers!" (Under no circumstances should you show them this: https://www.youtube.com/watch?v=BKorP55Aqvg )

This is entertaining, but also cringe; clients and product people aren't generally idiots. They just have requirements that they can't adequately express. Requirements capture is part of every eng job I've had.

Agreed, but as a former freelancer: Sometimes your customer doesn't know what they want and instead of figuring it out together they sketched together an internet-research-fuled plan that they want you to follow to the point, even if the plan is inefficient, doesn't solve their problem etc.

I usually managed to convince those people to come up together with a new plan while making sure they still feel like their original work is somewhat in there — after all I was the expert they came to with their issue, would be a bit idiotic to not pay for my expertise..

Sometimes this does not work, then I usually just told them I won't take that project. And projects like these don't make any sense, the customer will complain about their own planning mistakes as if it was your fault, you get angry, they get angry, everybody loses.

The best customers are those who know the problem they want to solve very well, as well as having some idea how a potential solution could look, but who thank you if you have an even better solution.

Re: Buttons as Finite Automata

#79
post #72

Also shows one of the fun aspects of many finite automata I encounter... If you right click it, it gets stuck thinking it's "pressed" until you click somewhere. As much as I like FSM in principle, I feel like substantially more than half that I've encountered in software have either failed to accurately model how a system actually behaves, or have been missing core states that are a natural fit for real-world use. It…

Inadequate use of FSM is what scares me a lot, especially in embedded development. The current state in software should be the result of sensory information whenever possible. Or at least state consolidations based on sensory information has to be thought through rigorously. Is there any literature on the topic?

Re: Buttons as Finite Automata

#80
post #77

Earlier quoted context omitted.

Huh. I never understood the terminology "radio button", and I have no memory of noticing such a thing in a car. But it could easily have been there; why would I have cared? I did have a tape player with buttons (play / rewind / stop / etc) that, when pushed, unpushed the other buttons. So I have a mental model for buttons of that kind. But I've never associated them with a radio. Also, I've never associated the radio…

I vaguely remember when I was a kid our hifi system had buttons like that, they were all round cylindrical buttons

For my tape player, the buttons were large rectangles with no border between them. If I recall correctly, they didn't sink in, but rotated - pushing one would depress one edge of the button without depressing the opposite edge.
Post reply on HN