4 ms·
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 a
by rektide 3y ago
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.
- mathgladiator 3y agoGreenspun'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 https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
- tshaddox 3y agoI think you’re looking for this: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule 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.
- quink 3y agoHalf that quote and half Henry Spencer's "Those who do not understand Unix are condemned to reinvent it, poorly."
- rektide 3y agoThis is an excellent additional contribution which I did not think of. Thank you all. Both feel real here.
- lowq 3y agoThat'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.
- btown 3y agoMy favorite iteration on this, linked there, is https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law 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.
- FridgeSeal 3y agoI 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.
- btown 3y agoAh yes! Thankfully on the writing side, headless browsers make this a lot less painful!
- astrange 3y agoImplementing 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.
- 8note 3y agoHa, 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?
- code_biologist 3y agoI 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).
- tlarkworthy 3y agoI 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.
- nailer 3y agoI 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?
- tlarkworthy 3y agoThey still go into trap states. If you try to remove default transitions your source code complexity explodes.
- nailer 3y agoHrm. 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.
- tlarkworthy 3y agoThe idiomatic calculator interface is actually very hard to implement without bugs https://mitadmissions.org/blogs/entry/designing-a-calculator-with-fsm-logic1/ 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
- qwtel 3y agoIn 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.
- samsquire 3y agoI 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_other 3y agoThe problem is that UI is complicated. It’s all edge cases and human factors.
- dgb23 3y agoWhile 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.
- keeganpoppen 3y ago> 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).
- marginalia_nu 3y agoI'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.
- kqr 3y agoThis 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.
- epolanski 3y agoBeen 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.