Thinking in Async

[Paul Tarvydas]

[from https://guitarvydas.github.io/2021/07/06/Asynchronous-Thinking.html]

To: FBP’ers

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.

Brief Example

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

It’s “magic”.

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.

Discussion

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.”

pt

https://guitarvydas.github.io

[Paul Morrison]

Beautiful!  Thanks, Paul T.

[Paul Morrison]

I think a key part of the puzzle is what I call the "pigeonhole effect"...  Again from my book:

The problem is to create a file OUT which is a subset of another one IN, where the records to be output are those which satisfy a given criterion “c”. Records which do not satisfy “c” are to be omitted from the output file. This is a pretty common requirement and is usually coded using some form of the following logic:
    read into a from IN
    do while read has not reached end of file
        if c is true
             write from a to OUT
        endif
        read into a from IN
    enddo    

What action is applied to those records which do not satisfy our criterion? Well, they disappear rather mysteriously due to the fact that they are not written to OUT before being destroyed by the next “read”. Most programmers reading this probably won’t see anything strange in this code, but, if you think about it, doesn’t it seem rather odd that it should be possible to drop important things like records from an output file by means of what is really a quirk of timing?

Part of the reason for this is that most of today’s computers have a uniform array of pigeon-holes for storage, and this storage behaves very differently from the way storage systems behave in real life. In real life, paper put into a drawer remains there until deliberately removed. It also takes up space, so that the drawer will eventually fill up, preventing more paper from being added. Compare this with the computer concept of storage – you can reach into a storage slot any number of times and get the same data each time (without being told that you have done it already), or you can put a piece of data in on top of a previous one, and the earlier one just disappears.... Although destructive storage is not integral to the von Neumann machine, it is assumed in many functions of the machine, and this is the kind of storage which is provided on most modern computers. Since the storage of these machines is so sensitive to timing and because the sequencing of every instruction has to be predefined (and humans make mistakes!), it is incredibly difficult to get a program above a certain complexity to work properly.

This is intimately related to Paul T's point about sync vs. async.   Early on I stumbled upon the Batch Update, which in the old days we had to write using synchronous coding, and it was a mare's nest.  Using asynchronous coding it is simple, beautiful, maintainable!  I will try to find a diagram for it!  The "Telegram Problem" is another similar one, and so is the "Same Fringe Problem" - http://wiki.c2.com/?SameFringeProblem .

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/9d2079ed-9466-4cb2-aaef-1b0129939b58n%40googlegroups.com.

[Raoul Duke]

also seen in deterministic (and possibly distributed) dataflow, in ascii (for good or for ill). 

[Ruud Steltenpool]

To me FBP is like being in a helicopter with binoculars that can zoom in and out, above a maze. Many other ways of programming are like being in a maze, where sometimes you can peek through/over walls a little, have long ropes to figure out some structure, but not have a drone with zoomable camera. I'm not sure if it really makes sense. Top-down versus bottom-up seems to fully catch what I mean/feel, it's more that you can easily go up and down layers and use our spatial senses/brain better with FBP. Makes any sense to you?

[Paul Morrison]

I like this image!  I am very visual, and have always thought that FBP takes advantage of this human capability.   This is also why, in DrawFBP,  I included the capabilty to switch rapidly between a diagram and its subnets: just click on a subnet block and you see the subnet in another window...