My inspiration for using components came from Harel’s Statecharts paper (plus the immediate need to control a 4-headed 68000).

I wrote a textual statemachine compiler for that project.

After that, I discovered that Harel’s Statecharts were really 2 technologies:

  1. HSM - hierarchical state machines (no concurrency, no orthogonal states).
  2. concurrent components.

I kept cycling on that idea and figured out how to compile diagrams to code.

Using PEG and PROLOG, it is easy to compile diagrams1.

Diagrams make the most sense when the boxes depict concurrent software components.

Using synchronous languages for diagrams tends to fail.

My diagrams are based on the EE paradigm.

I think in terms of discrete events and communicating state machines,

One needs the equivalent of structured programming for message-passing.

That’s something that is missing from the Actor model.

Enabling a paradigm is not the same as encouraging the use of a paradigm2.

Trees scale.

Graphs (which imply inter-dependencies) do not scale well.

We used to build POS embedded applications with some 300 components on 8-bit CPUs with very little memory (12K and up) (for IVI, since bought up by Ingenico).

Obviously, a system of 300+ components must be structured in some kind of hierarchy, to be understandable.

Again, having concurrent nodes in the hierarchy makes things more manageable. Current GPLs encourage anti-concurrent design3.

See Also

Communicating State Machines
Triples
Factbases 101

PROLOG For Programmers

Blog

Videos

References

  1. For more on this subject, search my blog for keywords such as factbases and triples. ↩

  2. If it were good enough to simply enable a paradigm, then we’d be coding everything, OOP and FP, in assembler. The paradigm needs to be encouraged (enforced), like what Smalltalk did for OOP. ↩

  3. Any language that uses a thread library treats concurrency as an after-thoughts and a second-class entity. ↩