Hacker News Reader

Comment by lostcolony | Hacker News Reader

I've seen this in practice, but it begs the question (and it might be answered in the talks): what is the alternative? That is, I have this corpus of rules and behaviors that I can express as an FSM...is there a better way of expressing it, given that I actually need something that behaves according to them?

View on HN

As another comment below points out, any non trivial software contains FSMs but they can express it in any number of ways. Haskell trying to avoid mutable state would probably pass around a constant data structure recursively through a series of pure functions. I find explicit FSMs difficult to reason about and find pure functions operating on complicated data structures much easier to reason about. It is irrational to conclude there is one clearest representation for everyone even within a single problem space. Experiment, find the one that suits you and show understanding to those who think and learn in other ways.

The mechanism for learning to think in state machines is message sequence charts. For each state there is usually a short list of Things That Can Go Wrong ( timeout, race condition, garble, inappropriate message ).

Ya gotta think like a clockmaker.

Erlang is doing exactly what you're saying here.

You are right - while there may be a simpler FSM that is equivalent to the one you have, the irreducible complexity that can arise from apparently simple rules is a feature of the problem domain. FSMs are part of the solution domain, and the best you can hope for in the solution domain is to avoid making things more complicated than they have to be. That does not rule out there being alternatives to FSMs that are easier to reason about.

If you have more than one layer with implicit mutable state, you are up for emergent behavior. It is not limited to FSM.

But FSM are just too easy, so people often use it to make implicit some state that would be explicit otherwise. In this sense, yes, they do cause emergent behavior.

The alternatives are joining your state at a single layer, making sure your states are really orthogonal to each other (very hard if both do IO), or making your state explicit so that you can at least verify once you find a problem.

So don't make state implicit. This is critical. Orthogonality is just something you do.

I've found it offends some people, but it works and generally, their way doesn't.

But the founding principle is "trust no one" in distributed systems.

I wouldn't put it that black on white. Orthogonalising implicit state is just great for managing complex behavior. It's a very powerful tool, and it can be made foolproof on lots of cases.

But if two layers do IO, you'll almost certainly want the state to be explicit.

I don't think foolproof costs all that much, especially if it's habit. YMMV.

I have a BluRay player with Java(tm). If it sits more than a day or twenty, I have to unplug it, count to ten and plug it back in. I have a TV that has seizures - loud, painful seizures ( that always test the ability of an amp connected to it to defend itself ) . Scares the crap out of the dogs.

This is not necessary. This is not good.

it begs the question: what is the alternative?

Here is one: https://news.ycombinator.com/item?id=11418855 (intended as a reply to your question but accidentally posted to the thread)

Reply on news.ycombinator.com