Hacker News new | past | comments | ask | show | jobs | submit login

I have mixed feeling about the hierarchical facility in statecharts. I've certainly found it helpful in some cases; for example, handling "cancel" events that apply to a group of states.

I've also seen huge, multi-level, multiple-parallel-region monsters that were impenetrable.

Now, no formalism is immune to abuse: "just because you can, doesn't mean you should". But I've often found that the simpler state model formalism - without hierarchy - has led to cleaner design and better separation of logic.

More generally though I do think state machines are somewhat underrated tools in the programmer's toolbox.




Agree.

I’m a huge fan of this approach when developing complex UIs, but you can definitely run into “state explosion”.

When you rigorously enumerate all the implicit states in your system you quickly realize that your system can have a lot of states.

It’s a balancing act. How much rigour do you need vs. how much code are you willing to deal with.

The implicit states will always be there whether you make them explicit via a state chart or not. But for simple things, it may not be worth the overhead.


Me three.

Ages ago, I implemented an Illustrator style direct manipulation user interface. We had spent so much time analyzing, documenting, specifying in prep.

My initial implementation, per our "perfect" spec, really sucked.

Turns out there's a significant amount of fit and finish to a direct manipulation interface that I wasn't able to handle formally with charts and machines. Ended up with a bunch of special cases. Unanticipated knock on effects were unsatisfying negotiations with QA/Test (how to test) and tech writers (how to describe) our product.

I've always wondered about that gap. Was I doing it wrong? Are there better formalisms? How'd Illustrator (and others) do their direct manipulations?

With the rise of touch UI, I anticipate the problem space (complexity of the states) has gotten smaller. For instance, no modifier keys. But that's just a guess.


To give another data point: https://ossia.io had three different tentatives for implementing its UI manipulation "manually" before reaching for (indeed complex) state machines which I spent at least 4-5 full-time days specifiying on paper for all their cases (following days of meetings trying to define informal specs).

It's the thing that ended up working, and still works 4-5 years after the fact & numerous modifications / improvements / new features. Also Qt with GammaRay allows to visualize them "live" which was an immensely useful feature to debug them during development.


Good insight. I think it's a blessing and a curse. currently i think me and my team have trouble identifying all those states and thus mis-understand or under-understand the complexity of some features. I want to use state charts to force us to look at all the states.

Of course I expect everyone will soon get annoyed at all these states we are tracking.


I agree too. I assume that state machines (SMs) are underrated because they are used in a "wrong" way which makes building them impossible: I mean most authors focus on listing and naming all the states, but in fact, they should not do that (IMO) but rather focus on events, conditions, and actions, which cause state transitions. Secondly, they should use hierarchical grouping the reduce number of edges in the state graph.

There are concepts like workflow engines and FLUX architecture which help in designing simpler SMs. For example, by limiting state transitions to events similar to how modern microservices communicate there will be less events. And actually many workflows themselves are implemented in (smaller) state machines.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: