Hacker News Reader

Comment by rektide | Hacker News Reader

What's the quote about "those who do not do X end up with an unintensional half built reimplementation of X"?

My personal recent example is a wizard in a web app built as a single major component, with some subcomponents, that goes forward and backwards through 3 different major flows depending on use case. It's been somewhat tamed over time, but we still find cases where an error on step X gets us into an unrecoverable state, sometimes with actual longstanding data impact or where closing & reopening the modal doesnt get the user back on course. With a state machine, I feel, things would be far more predictable.

Having some actual Computer Science in your coding can be a huge boon.

View on HN

In my view it's the other way around. If you stick to a state machine for your app logic, you'll end up with an unintentional half built reimplementation of a general purpose programming language.

The fact these state machines aren't the mathematical constructs from CS, but "extended" versions with "context" (this is where all the actual app state goes), should be the giveaway that they aren't a sufficiently capable model for the demands of UI programming. After you add extensions for every possible need, what do you end up with?

I understand the appeal though. UI development is a complicated mess, and people want a formula to make sense of it all. I've went through several iterations of these cookie cutter patterns form MVC to MVVMC++ to flux to redux to redux-saga to immutable.js to Recoil and so on. At best these marginally improve the situation, at worst they end up adding complexity on top of the inherent mess.

At the risk of missing out on the One True Way of doing UI development, I'll pass on this latest installment. I keep open the possibility that state machines "marginally improve the situation" though.

I am too looking for a solution to make UI development easier to understand and less complicated. I am working on a state machine formulation too.

I've worked on MVVM and redux. GUIs end up complicated and difficult to understand if you're not familiar with the codebase.

The problem is that UI is complicated. It’s all edge cases and human factors.

While that's true, there are also limitations and gotchas of Web based UIs that make state management very complex and messy. There are layouts that you _cannot_ express (with HTML/CSS/JS) without intermediate rendering steps and the whole paradigm of separating state and representation (React etc.) falls apart very quickly.

And before anyone asks: Yes, this comes up surprisingly often. Yes, alternatives have always been explored first. Yes, I'm up to date with browser capabilities. No, you can't say "no" to these designs when you're hired specifically because you can make things work.

Example of such a layout?

Do other UI building paradigms solve these issues more comfortably, whilst retaining (comfortable-ish hooks into) accessibility?

With Vue and Pinia, one doesn't even have to bother with patterns. Frankly, I think Redux does more harm than good. Their borderline incomprehensible documentation is a testament to that.

Redux shines when you have an actual "app" with a large dynamic "global" client-bound state that pops up in different places and needs undo/redo (Like a video editor, Blender,etc). And even then you preferably need some small helpers to make the experience smoother (slices from redux toolkit is a good example).

For most people doing a small CRUD pages that's just woefully overkill.

State management using redux (ngrx flavor) is the best way of managing application state I have discovered so far.

Simple structure, powerful, what do you want more?

Some people are really creative at creating dozens of boolean flags with lots of possible and impossible combinations. And some don't even correspond to screen in your figma file from designer (but can actually happen due to race condition... etc). You will really want a state machine that just list every possible state and transition in that case.

Hi, I maintain Redux and wrote most of our docs (including our current tutorials).

Can you give some details on which parts of our docs you feel are "incomprehensible"? I'm curious which specific pages you've been looking at, and for what purpose.

We've tried to organize the docs using the "Documentation System" approach described at [0]: Tutorials for teaching step-by-step, Explanations and How-To guides for specific topics, and References for API details.

Generally we want people to go through our "Redux Essentials" tutorial [1] as the primary way to learn how to use Redux correctly. It teaches "modern Redux" patterns with Redux Toolkit as the standard way to write Redux logic (including RTK Query for handling data fetching), and React-Redux hooks in components.

I'm genuinely interested in feedback on what explanations aren't clear and how we can improve things!

[0] https://documentation.divio.com/

[1] https://redux.js.org/tutorials/essentials/part-1-overview-co...

There you are.

I agree with you, the “extended” version of state machines with “context” is the problem with xstate. Modelling state transitions deterministically is great, but context and actions are too closely coupled to machine transitions, making it very hard to write generic or reusable state machines when you actually make use of these features. Had xstate focused on only transitions (like regular FSMs) and left context/data and actions/effects to other application-level abstractions, xstate would be widely compatible with many projects instead of requiring a heavy-duty paradigm shift in terms of how you model your application logic.

I agree that state machines alone are probably not sufficient, but they are frequently a useful way of modelling at least part of the interaction flow. Honestly they should probably be used more in all areas of programming (but they should not be used exclusively).

I think the sweet spot are state machines that don't take "context" as inputs but have richer effects in their transitions (if we're talking about Mealy Machines).

This way, the internal behavior of the machine is still deterministic and easy to reason about.

I found this tiny two lines in the erlang state machine docs that I've kept around for years because it's such a precise definition of how they need to work in practice:

"State(S) x Event(E) -> Actions (A), State(S')"

"If we are in state S and the event E occurs, we should perform the actions A and make a transition to the state S'."

The fn needs to yield both the new state and a collection of side effects of that transition that need to be handled somehow. You'll need side effects no matter what so might as well formally describe them in the SM, then handle them outside of it in a way that fits the language/framework/runtime. I think this is basically exactly what elm does and how a couple of the redux extensions work too.

I think you’re looking for this:

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Half that quote and half Henry Spencer's "Those who do not understand Unix are condemned to reinvent it, poorly."

This is an excellent additional contribution which I did not think of. Thank you all. Both feel real here.

That's a good one. I've been trying to find a source for: "If you try to write your own TCP, you'll end up with TCP, but slow."

Cannot for the life of me figure out where I read this.

My favorite iteration on this, linked there, is https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law :

> Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

And my own take:

> Every program attempts to expand until it can (a) interpret half of Common Lisp; (b) read and write mail; AND (c) implement a nontrivial subset of Quickbooks Online, including double-entry accounting. Those programs which cannot so expand are eventually forced to thus expand by the mythical force known as the Stakeholder.

One must embrace the inevitability of the "rule.trigger_logic" column, of the "how do we make this work like gmail" question, and of the dreaded interplay between "balance due" and "transaction/account adjustments."

Only then can one find inner peace.

I feel like this should be increased to include “read and generate pdf’s”.

I’ve worked at a concerning number of places now where needing to do waaaay too much with PDF’s has inevitably become a core part of the product.

Ah yes! Thankfully on the writing side, headless browsers make this a lot less painful!

Implementing half of Common Lisp is better than all of it, though, because of the rule of least power.

The advantage of state machines is that you know it doesn't do anything except for what you put in the state transitions.

I've always sort of thought of explicit state machines as a sort of failure state when it comes to finding a good abstraction for some logic. Explicit state machines are the sledgehammer that lets you bludgeon through the problem space regardless.

I get that they're an useful intermediate state for parsers and so, but still. I'm no fan.

This is a good point. The state machine abstraction is very low level. I guess what would be interesting would be domain-specific abstractions implemented on top of state machines.

Defining the domain-specific abstractions in the terminology of state machines may make them more approachable also to non-domain experts.

> Having some actual Computer Science in your coding can be a huge boon.

this is so, so underrated... i could get pretty flame-y in defense of this point, but a lot of said flame, admittedly, "doth protest too much", as someone trained to (allegedly) be a computer "scientist". but what i will say is that if i had a dollar for every time that software i rely on breaks and/or sucks because there is not enough "science"... there would be a lot more software that actually "works" (tm) in the world (xD).

Greenspun's tenth rule?

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Been there, and you make a terrific and common example.

Yes, you're right, FSM are terrific modeling wizards or complex autocomplete inputs.

That being said, you don't need full blown FSMs, you can often get away simply modeling and leveraging a type system for this purpose and only allow state transitions to happen through specific functions.

Essentially, the case you describe can be well modeled by a reducer-based redux-like flow with actions that lead to precise mutations.

One thing that I've done in the past was to use xState to model the transitions but then not use it in the actual implementation.

I find I got the same issues even with state machines. If the problem is complex, you have to consider every edge case with or without state machines. The essential complexity is the same.

I think the idea is the state machine makes you consider every possibility.

For example, what happens when an enemy gets shot when they are in the ‘dead’ state?

They still go into trap states. If you try to remove default transitions your source code complexity explodes.

Hrm. I used to not understand what state machines were (I don't have a CS degree) and mistakenly think they were adding complexity. I use them regularly now. I make my own, so they don't have default transitions to remove (beyond throwing 'not implemented' errors when I haven't built a particular transition yet), and I'd still say they're less complex than managing state without them.

Thinking about 'remove default transitions' - are you talking about using a particular state machine library? My default model is writing them. It's kind of like using a feature flag library when a hashtable with features for keys and boolean values will do. OK maybe use a library if the library adds realtime control etc, but not for the basic concept of flags - likewise a state variable and a single transition function work very well for state machines.

The idiomatic calculator interface is actually very hard to implement without bugs

https://mitadmissions.org/blogs/entry/designing-a-calculator...

FSM don't help with the bugs. You need analysis on top to actually make a dent in the bug count

Ha, I've been working on something similar recently and the big question is, do you want that state machine on the front end or the backend?

I think both are necessary in different circumstances. I use a simple litmus test: where does the state live to provide the best UX for my app if a user moves from their phone to a laptop and back again?

If the state needs to persist across devices it it server side (though a frontend cache can make sense), eg: onboarding flow or "task wizard" state.

Some UI interactions are much easier with state machines, but persisting state isn't a concern even across page refreshes, eg: complex animations or complex form validation states (especially validation that involves time or websockety things).

Reply on news.ycombinator.com