3 ms·

So, I'll start with a disclaimer - I've only futzed around with FRP in Haskell, and never for money. Somewhere on an old computer I've got some code to simulate

by jfoutz 4y ago

So, I'll start with a disclaimer - I've only futzed around with FRP in Haskell, and never for money. Somewhere on an old computer I've got some code to simulate a pool table. But it has been a few years. The pool table is pretty fun to model. You've got events, which are collisions, and you've got an evolving state that you can sort of fast-forward through thanks to elementary physics. if you want to sample at a given time, you can. You can calculate out the time to the next event (collision with another ball or bumper) For me, when I got to multiple objects interacting at different times it got really tough to store the state of the world. (like after the break) I didn't try to support angular momentum - but it would have been fairly straightforward to add. What I've been thinking about lately, is algebra driven design https://algebradriven.design https://algebradriven.design That'd really help with nailing down the data structures and operations on them. That book has a couple of really gnarly sequenced state with constraints examples, that came from real production code. There's no closed form solution to some problems (a lot! most problems!). So I think really nailing down a data structure, and providing operations on that data structure are essential. You, well, I need to create an environment where I can create tactics for solving special cases, without that code for the tactic getting smeared all over the code base. I'm a dilettante, I've got very little experience on the JS side of things. But from pure Haskell, I'm a reasonably sophisticated amateur. So take my opinion in that context. I think the automated tooling for finding laws presented by Sandy Maguire really have a lot of potential for Locking down those interactions - and opening up new ways of decomposing those interactions, to make more sophisticated descriptions of interactions. I'm not clever enough to find a closed form, but given some state and a time delta, I can work out a bunch of special cases - the interactions. Keeping that tidy is tricky. That algebra approach seems really promising. Again. I'm a dilettante. Take my opinion in that context. There are probably horrible corners where all this falls down. Anyway, the day is starting and it's almost time to go wrestle yaml.

mncharity 4y ago
Having a state algebra can also help with speculative execution, as when doing FRP-like complex event processing on human input device streams, while preserving responsiveness despite diverse latencies. Consider doubleclick. After a click, rather than pausing for 30 frames to see if a second click eventually shows up, you can act immediately, and if there's later a second click, retract and rerun with a doubleclick event. With incremental speech recognition, interpretation of past words can change as a sentence progresses, so "Launch the missiles!" can replay as "Lunch is mussels! In butter!". Keyboard and ml-based visual tracking have very different latencies. So when combining them (eg, which finger pressed the key, where on the keycap, and what were any other vision-derived key modifiers), you can pursue a guessed-at transition immediately, and then correct if needed when tracking finally coughs up the hand pose. Edit: Hmm. Well... having "retractable state transitions". "Algebra" has other implications. Edit edit: s/reversible/retractable/ - sorry.
- jfoutz 4y ago
  Yeah. Java swing early on actually paused the event loop waiting for a second mouse click to return a double click. If I recall, some platforms would drop those events while paused, others would queue them. I think X dropped, windows didn't. this caused some workarounds smeared across the codebase. It's never going to be easy, and somebody has to pick the "right" answer. With more structure, you can get more consistency. I may not like the answers, but they're consistent answers and so I can reason about them. Reversible state transitions is a whole other bag of mixed metaphors. But I'd still say, more structure makes it consistent, and then you can reason about it, and then you can maybe solve some of those cases.

by jfoutz 4y ago

mncharity 4y ago

Having a state algebra can also help with speculative execution, as when doing FRP-like complex event processing on human input device streams, while preserving responsiveness despite diverse latencies. Consider doubleclick. After a click, rather than pausing for 30 frames to see if a second click eventually shows up, you can act immediately, and if there's later a second click, retract and rerun with a doubleclick event. With incremental speech recognition, interpretation of past words can change as a sentence progresses, so "Launch the missiles!" can replay as "Lunch is mussels! In butter!". Keyboard and ml-based visual tracking have very different latencies. So when combining them (eg, which finger pressed the key, where on the keycap, and what were any other vision-derived key modifiers), you can pursue a guessed-at transition immediately, and then correct if needed when tracking finally coughs up the hand pose. Edit: Hmm. Well... having "retractable state transitions". "Algebra" has other implications. Edit edit: s/reversible/retractable/ - sorry.

jfoutz 4y ago
Yeah. Java swing early on actually paused the event loop waiting for a second mouse click to return a double click. If I recall, some platforms would drop those events while paused, others would queue them. I think X dropped, windows didn't. this caused some workarounds smeared across the codebase. It's never going to be easy, and somebody has to pick the "right" answer. With more structure, you can get more consistency. I may not like the answers, but they're consistent answers and so I can reason about them. Reversible state transitions is a whole other bag of mixed metaphors. But I'd still say, more structure makes it consistent, and then you can reason about it, and then you can maybe solve some of those cases.