[boost] [msm] Review

Subject: [boost] [msm] Review
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-12-13 18:25:59

Ugh, I have not had time to deal with MSM the last week, which is why I now have to quite hastily report my take on this library. An upside of this haste is that it will reduce my blabbering, which has already irritated a few people in this thread :-)

First of all, and probably not a big surprise to anyone having followed this thread: there is already an FSM library in Boost, which has covered my needs in two projects, and quite possibly my needs in most applications. And, in order for me to want to include MSM, it needs to be significantly better, in terms of use (interface) or performance.

Alright, let me get straight to the recommended bullet points for a review:

- What is your evaluation of the design?

It is very good. It actually gives me the same vibes that Boost.Graph does. And those are great vibes. They share part of the meta-programming style (using Boost.MPL) of Statechart, but does so in a better way. There are two important great design decisions:

1. Not coupling FSM logic to the individual states but to the machine itself. This is manifested by the separated transition table or eUML equations. This is conceptually aligned with the mathematical notions of FSM's.
2. The separation between front and back end, enabling multiple API's (of how to define the transitions); this latter point is also used by the eUML interface, which differs widely from the old one (in previous versions of FSM) and that of Statechart. In fact, eUML definitely warrants MSM the label "Xpressive for FSMs"

- What is your evaluation of the implementation?

Well, two things:
1. It has not crashed ;-)
2. It is very fast. In fact, with most of my examples, using non-nested but guarded machines, with less than 80 transitions, it is around six times faster than Statechart.

- What is your evaluation of the documentation?

It is simply great EXCEPT for lack of instructions on how to actually leverage the design decision to separate front and back end fully, i.e., helping me to define my OWN front end or back end for MSM. So, I must take the design claim of separability with a tiny grain of salt.

- What is your evaluation of the potential usefulness of the library?

Great

- Did you try to use the library?  

Yes

 - With what compiler?

Unfortunately only with (Apple's) GCC 4.2.3 on OS X Snow Leopard.

  
 - Did you have any problems?

None, well, except for my divergence in creating my own meta interface for MSM (and Statechart) and the quirks of Boost.PP :-)

- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

An in-depth study.

- Are you knowledgeable about the problem domain?

I have studied all kinds of graphs theoretically, at a deep level, including DFA's, regular graph theory (and category theory), as well as various computational theories. I have used DFA's in most non-trivial projects knowingly for 23 years but a bit longer unknowingly. This latter point is important: I am quite aware and knowledgeable about the necessity (or benefit) of actually making the state machine of a solution explicit. I am not a big fan of extensions of DFA's, though, such as the state charts found in UML specifications. I.e., I think those just diffuse the beauty (if life is not that clean cut, make it so ;-))

SUM: I demanded much better usability or performance out of the second girl to the party, and MSM covers both those aspects, especially with their eUML interface, so I must vote YES to the acceptance of MSM into Boost.

Yes, yes, yes!

/David