There is still another way to drive a computer, other than compiling code for it or using an interpreter to handle the specifications written in some programming language. And that’s by leaving the imperative world of “do this, then that” behind and switching instead to a declarative or rule-based approach.

What if we could define the behaviour of our application in terms of conditions, events, rules, triggers, message, logic, and/or streams, in some way?

There are (again) many ways to follow such an approach. One technique is Flow Based Programming (FBP), which was originally invented in the 1970’s, and has seen a recent revival in projects such as NoFlo and Node-RED. FBP is usually presented as a graph:

Each “node” represents a piece of functionality (i.e. code), with messages flowing in and out of nodes according to the connections set up by the designer. Each computational task, hardware interface, and user interface element can be a node, with events and messages triggering the activation of other nodes. And on-demand dataflow orchestrating it all.

In the case of NoFlo and Node-RED, the implementation language is JavaScript and the processing takes place in Node.js on the server and/or the web browser on the client side.

But there is also a MicroFlo implementation, which runs on microcontrollers, and which aims to require very little processing power and memory resources.

Common in all these designs, is the fundamental split between components (modular units of code) and connections, tying it all together. The nice thing is that the set of connections and the settings needed to configure all the components are data, not code. So… given a sufficiently complete and powerful set of generic components, we only need to create and send around a fairly small data structure to represent our application and its behaviour!

It’s a bit like pre-compiling and uploading all the code we might potentially need (once, or at least not very often), and then “linking” the pieces together lazily, at run-time.

One useful property of data is that it can be inspected and used in different ways and places. An interesting example is Embrio, which has an extensive graph editor to pull all the pieces together, set up the connections between them, and configure each component:

Up to a certain point, this approach even lets you run a simulator on the “big” computer (Windows only), while designing the system, and then generating the data (and code, in the case of Embrio) which can be uploaded to an attached Arduino board.

(unfortunately, Embrio is not open source: a major concern when choosing a foundation)

Last but not least in this series on data-driven declarative and visual languages, there is the Finite State Machine (FSM). This models a system which can be in different “states”, and which transitions from one state to the next based on specific events – again often visually presented as a diagram:

One product which uses FSM’s (and nested FSM’s) as its core is Quantum Platform (QP). There is a lot to see and go through on their website – with many videos and tutorials.

All this visual stuff might seem like a gimmick for non-techies, but there’s a lot more to it than to “avoid having to learn a programming language syntax”. For one, it makes it very easy to decouple multiple activities and deal with logic in parallel. With flow diagrams and state machines, parallelism comes naturally – things “just happen” when their time comes. Which is equivalent to saying that such systems are inherently asynchronous in nature.

The other valuable property of a visual representation of an application, is that it is very easy to go back to it later and see how everything fits together – literally, in fact! Such designs become self-documenting, with zooming and panning to help us find our way.

Other examples of advanced graphical design systems are Pure Data and MAX/MSP from the audio world, and Scratch – a tool which can teach very young kids about programming.

Finally, is an aspect which may end up being one of the most important in the world of open source software: software designs which integrate different levels of technological abstraction allow people with different skill sets to work together and complement each other. The component designers can chisel away (in C/C++) to create beautiful little generic components, while the application builders can select from a pool of such components to create magnificent working projects. This benefit applies equally to language runtimes and interpreters, by the way – not just these data-driven architectures.

Collaboration requires coexistence and interoperability. And Flow Based Programming or State Machines might well turn out to be attractive vehicles for this level of modularity.

[Back to article index]