goflow

The core of the FBP principles are the holy grail of true componentized function architecture. Instead of losing yourself in ever more complex syntax convolutions as has happened in a lot of functional programming, you make the components (even long running stateful ones) self contained with ports for data input and output as the sole means of communicating with them, over buffered channels to allow asynchronous computation, and most importantly keep the network definition separate. Just this idea in itself is just brilliant. Hats off to Mr Morrison for that! It allows to decouple complex software into reusable components, without clever FP syntax. (Though, FP is perfect for implementing the components themselves. It just doesn't really scale all too well for whole program architecture, in my experience). One point to note: The visual co

Yes, I have been checking reactive streams, but they seem to take a similar approach as most other functional languages supporting chained lazy-evaluated functions. Even though they have specialized functions and constructs for branching out and merging, I'd argue that being limited to chaining functions, IMO it quickly grows unmaneagable when dealing with any more complex data flow networks. AFAIS, you'll get super-long chains of function calls, that are really hard to change, or inspect. Compare that with the syntax proposed in the post, or some other FBP syntax like the one in GoFlow [1], where you define each connection between an outport and an inport on one line. IMO this gets exponentially more manageable, readable and maintainable. [1] https://github.com/trustmaster/goflow#basic-example

Yep, there is https://github.com/trustmaster/goflow for that

Interestingly, uses GoFlow [0] (Flow based programming[1] lib, by Vladimir Sibiroff [2]) under the hood, and has a whole section on FBP, at [3]. Was in fact playing with the idea of using it for bioinformatics processing some 1 year ago (see [4] for components and [5] for an example program) and thought it was a great idea :) Refs: [0] https://github.com/trustmaster/goflow [1] http://www.jpaulmorrison.com/fbp [2] http://twitter.com/sibiroff [3] http://www.antha-lang.org/docs/concepts/flow-based-programmi... [4] https://github.com/samuell/blow [5] https://gist.github.com/samuell/6164115

For something more Erlang:ish (but better), see the Flow Based Programming implementation by Vladimir Sibirov, GoFlow: https://github.com/trustmaster/goflow . It lets you give your components names, and the inports of the components are somewhat analogous to Erlang inboxes as far as I can tell. But then it improves on the Erlang actor/mailbox concept by keeping the "wiring" of the connections between boxes completely separated from their implementation, which lets you change the data flow much more easily (hook in a monitor, logging facility, and extra test mock or whatever ... it is crazily powerful when you start to think about it!). GoFlow is of course not the only FBP implementation, but a Go implementation makes quite some sense I think. If you wonder what the Erlang creator (Joe Armstrong) thinks about FBP, you can find his comment