[FloNeu]

Well i feel the abstraction itself doesn’t really hinder… what hinders an i realized costs me lots of time is laying out a good looking machine-layout… the auto-layout for machine introspection still is terrible and currently can’t be used with the layouts in the editors. Also I often end up to having copy the machine json back and forth and this usually requires tweeting as Machine inputs still can’t be mapped using strings and I often end up missing some and then wonder why stuff isn’t working as now errors are automatically caught in the machine. What I really like is that I can visualize my programs and clearly communicate a system using the graphs and delegate the parts that have to filled in. I think it’s also great for documentation and making sure a program is built in a nicely testable way and state is only updated at the appropriate times and places (you need to use an assign action). Model-based testing is also a nice feature… as are the ability to restore machine states at later times using saved state or replaying events. Although I never have done it I enjoy the thought of just taking my machine and put it into another web-fronted and only rebuild the UI by binding the view to state/context and interactions to basic dom events. All in all I think it can have big benefits of having a UML like visualization of your program that can be introspected live at run-time and isn’t immediately outdated because nobody bothers to keep it up to date after a code update (because it is the code). But it surly is a bit of a learning curve… but I encourage you to just try it out beginning with very small machines and build from there. Many of my problems come from just trying to build a giant machine system with many communicating actors from the start. Which totally isn’t needed to assess its features/drawbacks