Your job is NOT to build more FBP components.
Your job is to teach others how to build FBP solutions.
You know how to program in FBP. Most people don’t know, but they think they know.
Example: functions cannot describe what happens when a component consumes input but produces no output. There is no f(x) for this situation.
Async thinking has no problem with this concept.
In an async solution, one might use “consume-but-produce-nothing Components” - but, that kind of solution is not expressible in functional (synchronous) thinking
If you use f(x) notation, you end up not being able to even *think* about this kind of solution.
It’s akin to having Natural Numbers with no 0 - you think that you can talk about numbers, but certain kinds of things just can’t be expressed.
Corollary: Asking programmers to specify Async Components and FBP workflow is asking them for Rube Goldberg ideas derived from synchronous-only thinking.
Programming in FBP is VASTLY different from sequential programming, yet, the words used to explain both are frighteningly similar. This means that it is virtually impossible to explain how to use FBP using only words (I’ve been trying, I’m up to 330+ blog posts, but have yet to find the sweet spot).
Henry Ford is attributed with saying “If I had asked people what they wanted, they would have said faster horses”.
The first use of electric motors was to power textile mills, by pumping water uphill to make artificial streams that ran the water-wheels that ran the textile mills.
At first, it was thought that computers were only good for building ballistics calculators.
I would suggest that, instead of the question “what components do you want?” and “what workflow do you want?”, the question becomes “what applications are wildly popular?”. Then, re-implement one such application in FBP.
“Give a man a fish, he eats for a day. Teach a man to fish, he eats for a lifetime.”