Post about Asynchronous Thinking

[Alfredo]

http://scriptogr.am/alfredo/post/asynchronous-thinking

Please speak your mind in this thread.

[Matthew Lai]

On Friday, 28 February 2014 22:57:18 UTC-5, Alfredo wrote:

http://scriptogr.am/alfredo/post/asynchronous-thinking

Cool. And it is very do-a-ble. I can do async processing with my poor-man cluster of
7 computers: from the most antique one (16-year old computer) to the ultra thin ultrabook
to the smallest RasPi single board computers, using nothing but single threaded processes
running async I/O, communicating with each other using TCP sockets.

Please speak your mind in this thread.

My mind runs in loops, don't know where to start, where to stop, so very hard to speak here :)

Watch out for the loopback connections. Always a challenge to face a deadlock!

Matt

[Paul Morrison]

Absolutely!  When was that Sutherland speech made?

BTW I talk about this at the beginning of http://www.jpaulmorrison.com/fbp/endchap.shtml - and I never that Sutherland was thinking about the same things!  You might also want to look up some of Gelernter's remarks in connection with his Linda system.

Regards,

Paul

[Paul Morrison]

On Saturday, March 1, 2014 9:28:04 AM UTC-5, Paul Morrison wrote:

Absolutely!  When was that Sutherland speech made?

From internal evidence in the video, it was in 2009 or later.   Ivan Sutherland seems a pretty high-powered individual - here is his Wikipedia biog: https://en.wikipedia.org/wiki/Ivan_Sutherland .

Thanks for pointing us at the video!

Paul

[Alfredo Sistema]

He made the original Sketchpad system, a pioneer in many aspects. Bert Sutherland, his older brother made pioneered on line visual programming too, an interesting family.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Paul Morrison]

The following remarks were sent to me by Herman Van Goolen of the Netherlands, an IT architect with many years of experience.  He has had repeated problems posting comments to the Google Group, so he has asked me to do it for him.  Hopefully this will stir up some more discussion on the topic.  Here are his remarks:

Reading the reactions on the "Asynchronous thinking" page by Alfredo, and especially on the presentation “Some Thoughts About Concurrency” by Ivan Sutherland, I would like to share some of my ideas about it with you.

– The work of the Asynchronous Research Center is hardware oriented.

– “Asynchronous” is used in the sense of “without the synchronization of a clock” and as such it is not related to the asynchronous processes of FBP.

– There are probably more essential reasons why we have trouble dealing with concurrency in application development.

In short: The presentation is not really significant in relationship to FBP, but the way Ivan Sutherland addresses the communication problem may help us better to understand the value of the FBP concepts.

 

In the beginning of his presentation Ivan Sutherland stated:

“Concurrency is not fundamental to our thinking.
We train our programmers to think sequentially. …
Computer languages all followed the sequential model. …
It was how we thought…”.

My immediate reaction was: Are we thinking sequentially? Is our brain working sequentially? Our body shows the opposite. Watch how a pianist is able to control the numerous muscles of his fingers simultaneously, at a furious pace. The human brain is a kind of multi-multi-…-processor, with multiple connections between the neurons.

And as the same type of neurons are involved in our thought processes, we can assume that concurrent thinking and thinking about concurrency should not be a problem to our brains (at least when we are able to be/remain focused on the processes).

But the communication between the brain and the outside world is generally limited to a sequence of related elements. Textual languages are (mainly) written and read in a sequential way. As such our concurrent thinking may become almost imperceptible as the result of our sequential communication process.

 

We must look for ways to improve the communication of our thoughts about concurrent activities. Visual programming languages, – text enhanced by graphical elements,– may improve the communication (and in addition, it helps us to be/remain focused on the processes). But (especially at this moment) the production of ‘visual programs’ may be a (too) heavy load to generalize its use. FBP provides the possibility to support asynchronous thinking at the higher level and use synchronous thinking at the obvious lowest level.

[ Tomi Maila, with his ExpressionFlow, tried to introduce graphics up to the lowest level, but did he give up? Efficiency is often decisive. ]

 

In relationship to the use of those two levels, I would like to refer to your statement in your book about things like 'preheating' and concurrency. The cook initiates the actions things in a sequential way.  The brain converts the concurrent things into a sequential list. If the cook repeats this sequence of activities several times, it will be recorded in what neurologists call 'procedural memory'. Even our brains seem to recognize that (fixed) procedures are superior when dealing with simple things.

 

Kind regards,

Herman Van Goolen

[Matthew Lai]

On Thursday, 6 March 2014 12:40:47 UTC-5, Paul Morrison wrote:

The following remarks were sent to me by Herman Van Goolen of the Netherlands, an IT architect with many years of experience.  He has had repeated problems posting comments to the Google Group, so he has asked me to do it for him.  Hopefully this will stir up some more discussion on the topic.  Here are his remarks:

– “Asynchronous” is used in the sense of “without the synchronization of a clock” and as such it is not related to the asynchronous processes of FBP.

Sounds like null convention logic here i.e. async digital circuit that does not require a system clock to run.
See

http://www.theseusresearch.com/NCLPaper01.htm

and
 
http://ca.wiley.com/WileyCDA/WileyTitle/productCd-0471798142.html

for more info.

Matt

[Paul Morrison]

This topic seems to have gone dormant, but it seems an appropriate place to talk about synchronous vs. asynchronous approaches - in the context of a specific problem, the diagram that I call the "NoFlo Clock" - maybe its authors have a better name for it.  It can be displayed by entering  http://noflojs.org/noflo-ui/#example/6608098 .  Click on this web site, wait a bit, and then click on the "not started" arrow in the top righthand corner (almost invisible on my machine, but I gather they're working on that). 

You can now see the clock running, and if you click on any line, you see the packets that are travelling across it.  So that is very cool indeed!

The problem for me (aka Morpheus, "classical" FBP proponent, etc.) is that this is a totally synchronous implementation, and I worry that it doesn't help programmers to make the jump from synchronous, von Neumann, thinking, to asynchronous FBP thinking.   Eric H, are you reading this?!

So I started by redrawing this diagram using DrawFBP, to help me understand it better.  I also renamed Split to Copy, as I feel that is closer to its function.  Here is the diagram.



BTW, in classical FBP you can't connect one output port to multiple input ports, but Copy doesn't need to do this anyway, so I have shown separate output ports.  Also, you don't need a "bang" as processes with no (non-IIP-connected) input ports start immediately anyway.

Unfortunately, this diagram won't work in "classical"  FBP, as there is no guarantee as to when a particular IP is going to arrive at an input port, or for that matter, when the process is going to decide to receive from that port.  

I also think, and have said elsewhere, that mathematical functions are not a good fit with classical FBP.  If you have components called "multiply", "add", "divide", then basically you have a diagrammatic version of math, and you might as well use formulae, which are also highly visual, and familiar to most users.  In any real-life app, you would have to split your IPs up into separate fields, and then it is expensive and deadlock-prone (in classical) to recombine them later.

So my question (which I actually posted to another topic) is: how would you design the clock app to take advantage of the flexibility of "classical" FBP?

Now I am assuming that you want the clock to reflect the actual current time - IMO this means you have to tightly couple obtaining the date/time with the position of the clock hands... which basically means you have to put these two bits of logic in the same FBP component. 

I have actually written some skeletal Java to rotate 3 hands in real time, and it works great!  But it is one component. 

What I do is get the current time, calculate the angles for the 3 hands, and recalculate the angles every second.  I only have to get the current time once.

This single process of course could then run under JavaFBP, but the network would be trivial - exactly one process!   However, suppose we want to take advantage of the multiple cores on modern machines, how can we split it up?  Well, one possibility is to have a separate process per hand.  Of course, each process would have to get the current time - once - but after that it would just run in solitary splendor!  Of course, that's assuming that you can write to the same screen panel from different threads - I'm not at all sure I can do that using Java Swing, which is the tool I used, but maybe SVG can support it.   Even then, you would just have 3 processes, with very little communication between them.  And since you only have to do a simple calculation once per second, I'm not sure there is much point!

I also have one meta-question for the NoFlo team: given that the big advantage of FBP (for me and lots of other people) is maintainability, what changes did you feel might need to be supported by the way you divided up the logic?  For me, being able to use an off-the-shelf divide is not a good enough reason to make divide a separate component!  Every programming language supports divide at a pretty low level!

As I said above, I worry that NoFlo, or at least one of the examples you use to promote it (and I do grant that it looks very sexy!), doesn't help programmers to make the jump from synchronous, von Neumann, thinking, to asynchronous FBP thinking.   I think we all agree that it is the latter that has enormous potential for the future, but most programmers are stuck in a synchronous, control-flow, way of thinking about computers.  As I have said many times, you have got to get programmers when they are young - if possible before they pick up synchronous bad habits !  Anyone want to design some education for high-schoolers?   Now there is a challenge!

Regards,

Paul M

[Tom Young]

Interesting question, Paul.   I would use feedback to reduce hand position errors due to

latency in the network,    something like  (CONTROLLER)>(CLOCK)>(ComputeHands)>(DisplayHands)>(CONTROLLER).   This is most interesting if DisplayHands runs on a different computer.  The controller would attempt to minimize the delta-t.

---twy

      

Thomas W. Young, Founding Member
Stamford Data, LLC
47 Mitchell Street, Stamford,  CT  06902
Phone: (203)539-1278
Email: TomY...@stamforddata.com

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

For more options, visit https://groups.google.com/d/optout.

[Forrest O.]

The clock example was my first attempt at client-side NoFlo, and probably represents "Meemoo/browser-animation thinking" more than NoFlo/FBP thinking. I think that it is OK to have it as a simpler example. We can note that it is synchronous, and come up with a separate asynchronous example.

core/MakeFunction is a good component to put in arbitrary js formulas. I might update the clock example with those instead of the Divide components to be more clear about the math.

[Paul Morrison]

Both good ideas, Forrest!  I'd like to see those changes made to the diagram, and to the comments. 

A good network for the asynchronous modes might also be the CSV Viewer and its various iterations,  in the Appkatas article that I referred to earlier - http://clean-code-advisors.de/download/Team%20assessment%20-%20CSV%20Viewer%20Iteration%20I.pdf

Regards,

Paul

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

For more options, visit https://groups.google.com/d/optout.

[Paul Morrison]

Sorry, I should have said - the more general level for the Appkatas is at http://geekswithblogs.net/theArchitectsNapkin/archive/2011/06/25/appkata---enter-the-next-level-of-programming-exercises.aspx

P.

[Paul Morrison]

On Thursday, March 13, 2014 2:31:45 PM UTC-4, Paul Morrison wrote:

 I worry that it [examples like Forrest's clock] doesn't help programmers to make the jump from synchronous, von Neumann, thinking, to asynchronous FBP thinking. 

Nobody seems to have picked up on this comment, so I thought I would try to highlight it.  For me, it is the asynchronous nature of FBP that opens up so many possibilities that synchronous programming cannot provide.  And this is the characteristic that so many programmers seem to have trouble with...  and synchronism has a habit of sneaking in even when one thinks one is convinced of the advantages of asynchronism.  And surely the real world is asynchronous, so why should we be so afraid of thinking this way?

I do have a theory, described in my book, that programmers get very nervous - based on many very valid bad experiences with conventional programming - if they can't control the exact sequence of events in a program.  And yes, in conventional programming, this is important.  However, in FBP, the two laws of FBP suffice to ensure that processing happens correctly, and completely (see p. 30 of the 2nd edition of the FBP book).   This pure synchronous approach to programming is a legacy of the days when computers had a single instruction counter, and were oriented towards calculating ballistics tables, and doing other repetitive mathematical tasks.  It is actually not that well-adapted to doing business applications, and this was spotted as early as the 1950s.  Here is a quote from "Faster than Thought" (Bowden):

“It always outrages pure mathematicians when they encounter commercial work for the first time to find how difficult it is.” (p. 258)

and further on:

“...it is so hard in practice to get any programme [sic] right that several mathematicians may be needed to look after a big machine in an office. ... It seems, in fact, that experienced programmers will always be in demand” (p. 259)

As Eric H and I were discussing a few days ago, it seems to be well accepted that programmers' mental habits are strongly influenced (I might almost say "determined") by the language they were first exposed to...  And the vast majority of programmers' first language was Basic... or FORTRAN.  Ergo, synchronous thinking!

In my case, my first "language" wasn't even a computer language - I spent a couple of years designing business applications using Unit Record - see https://en.wikipedia.org/wiki/Unit_record_equipment .  Unit Record was in fact (as I came to realize only fairly recently) highly asynchronous and component-oriented - I even remember doing a form of multithreading on my first computer, the IBM 650 (https://en.wikipedia.org/wiki/IBM_650 )!  So I wasn't brainwashed into accepting that synchronism was the only way to think!

So, my concern is how do we get programmers who don't have the advantage of early asynchronous training to think in this new way?  Maybe it isn't a problem for the next generation, trained as they are on video games, but we've had 1 whole generation (maybe 2) intervene between the discovery of FBP and the present.  And I would really like great popularizers like Henri and Dan, and artists like Forrest, to come out very strongly in favour of asynchronism.  Maybe they do, but I have missed it...?  I also would like schools to teach kids about computers using some kind of very visual, multithreading, language, along the lines of Scratch.  NOT BASIC!!! (Sorry!)

You see, I don't even think there should be a library called noflo/math - if I were running the project, I would deprecate it.  I actually think at some level, it encourages bad mental habits!   IMO its only advantage is to allow expressions to be drawn in graph form, and, as I said in the March 13 note, mathematical expressions are already somewhat visual - so why do we need to draw them as pretty networks...?  Mathematical graphs even behave differently from FBP graphs, so a line in one doesn't really mean the same as a line in the other!

I do agree of course that being able to build systems from componentry and reconnect them easily is a plus, but if we are still in a synchronous mindset, I think that's a real problem!

I'll finish this rant now, and ask for feedback!  I don't want to cause a schism in the ranks, but I think we have to be more aware of the need to move away from synchronism - no matter how pretty it looks - and promote asynchronous thinking, starting with schoolkids!

Best regards to you all, and have a nice weekend!

Paul M. (aka Morpheus)

[John Cowan]

Paul Morrison scripsit:

> I do have a theory, described in my book, that programmers get very nervous
> - based on many very valid bad experiences with conventional programming -

Conventional asynchronous programming, I suppose you mean.

> As Eric H and I were discussing a few days ago, it seems to be well
> accepted that programmers' mental habits are strongly influenced (I might
> almost say "determined") by the language they were first exposed to... And
> the vast majority of programmers' first language was Basic... or FORTRAN.

I think this is no longer true, but it is true that programmers learn the
synchronous subsets of Java or Python first.

> So, my concern is how do we get programmers who don't have the advantage of
> early asynchronous training to think in this new way?

The trouble is that when programmers *are* exposed to asynchronous
programming, it comes in the form of threads and condition variables,
which are painfully hard to reason about. The advantage of classical
FBP architecture is that it promotes safe sequential thinking within
components, and safe asynchronous thinking when connecting them.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
"Your honour puts yourself to much trouble correcting my English and
doubtless the final letter will be much better literature; but it will
go from me Mukherji to him Bannerji, and he Bannerji will understand it a
great deal better as I Mukherji write it than as your honour corrects it."
--19th-century Indian civil servant to his British superior

[Alfredo Sistema]

Forrest's experience is with his own system called meemoo, which is really neat, but akin to an applicative language, and those designs can work on noflo too due to it's "reactive" nature.

I think that the motivation for fine grained components like add or divide, etc, is that a component library has to start somewhere, and such simple components are a good fit. Of course you can outgrow such things, but why remove it, maybe somebody has a use for it.

There are two components that replace this behavior http://noflojs.org/library/noflo-calc/ , which is more in line with classical fbp designs i think.

I propose a challenge that illustrates the problem with fine grained componentry, and it is FizzBuzz. http://en.wikipedia.org/wiki/Fizz_buzz

This simple problem is supposedly used to test candidates on extremely basic programming ability. Solving this kind of problem with fbp and fine grained components like modulus, joining strings, etc, is really time consuming and brittle. A task you can complete in your language of choice in a minute.

Can you ( anybody in the mailing list ) implement this with general pourpose components in a clear and maintainable way with little effort? I'd like to see it.

On a related note, an educational component library for noflo could serve as a tool to teach kids and grown ups alike, similar to what logo did for procedural programming, or other similar efforts involving a simple robot like entity that moves around the screen and picks up objects, etc.

I was considering some sort of imaginary factory that the user has to build and or edit to produce the required goods, in a game like environment. Connecting machines together, getting requests from clients, shipments for parts, etc. What do you think ?

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

For more options, visit https://groups.google.com/d/optout.

[Forrest Oliphant]

If the clock were in the real world, it would be driven by a box of gears, which seems pretty synchronous to me.

Could there be some asynchronous metaphor with 3 GPS satellites beaming a timestamp and my phone triangulating its position on the earth?

[Humberto Madeira]

Hi Paul,

On Saturday, March 15, 2014 12:21:05 PM UTC-4, Paul Morrison wrote:

I do agree of course that being able to build systems from componentry and reconnect them easily is a plus, but if we are still in a synchronous mindset, I think that's a real problem!

I'll finish this rant now, and ask for feedback!  I don't want to cause a schism in the ranks, but I think we have to be more aware of the need to move away from synchronism - no matter how pretty it looks - and promote asynchronous thinking, starting with schoolkids!

I  don't disagree about the need for a more asynchronous approach.  In fact, my framework takes pains to keep things as asynchronous as possible.

And I don't particularly want to give feedback on the specific example, one way or the other...

However, we cannot lose sight of the fact that in reality, we are performing all our voodoo on top of a great big von Neumann engine, and it isn't really cut out for asynchrony.

We have to be careful that we don't use too much asynchrony below a certain level of granularity.

In actual practice, the code inside a primitive Component typically runs in the normal Von Neumann model 

because it has to be written in the underlying language - which is usually very von Neumann.

Not to mention the von Neumann processors running underneath even that.

So for me, the boundary is clear.  Von Neumann on the inside and Morrison on the outside :-)

But the benefit of componentry does't have to be limited to the outside.  

Some componentry can be used even on the inside - just a different kind of componentry (of which there are plenty of examples).

And if there is componentry, it should be as pretty as reasonable.

So until and unless some other, more asynchronous foundation becomes available, 

I believe we are going to continue spending at least some time with Herr von Neumann, in one way or another.

.

--Bert

 

[Paul Morrison]

Thanks to all the people who have posted responses to my rant - so far - and I hope there will be more!  A very intelligent bunch of comments IMO, and thought-provoking too!

On Sat, Mar 15, 2014 at 4:37 PM, Humberto Madeira <kuna...@gmail.com> wrote:

So for me, the boundary is clear.  Von Neumann on the inside and Morrison on the outside :-)

This is fantastic - and not just because my name is on the outside - I would be just as happy calling it Gelernter or even Hoare... or FBP!  :-)

I never meant to imply that we should go synchronous inside components - sorry if I gave that impression.  I actually think that that is a key part of the architecture.  The machines in the Unit Record environment were actually synchronous beasts - they were just asynchronous relative to each other.

Keep the feedback coming!

I'll take a look at FizzBuzz... :-)  And what do people think about Forrest's idea?

How about the Appkatas - what is interesting about them for me is that they really stress maintainability...

[Matthew Lai]

Paul,

I occasionally demo the attached FBP network during my job interviews to showcase FBP capabilities.
This is "hello world" FBP style: 3 IPs move through the 9 identical components, each component
displays the content of the IP ("hello world" with red, yellow or orange colour) for half a second before
forwarding the IP to one of its connected neighbours, selected by a random number generator.
The end result is a flashy display of 3 "hello world" messages, in different colours,  bouncing around.
For those who remember the old FBP website, does the bouncing ball animation ring a bell?

Not sure if this is a good example to showcase the async aspect of FBP.
In my implementation it is truly async mode; in fact a distributed async running mode, with the
middle row components running on the ultrabook machine, top row running on one RasPi board and
the bottom row running on another RasPi board.

But I usually get the "wow" look from the folks interviewing me :)

Matt

[Paul Morrison]

On Sat, Mar 15, 2014 at 3:23 PM, Alfredo Sistema <sistemas...@gmail.com> wrote:

There are two components that replace this behavior http://noflojs.org/library/noflo-calc/ , which is more in line with classical fbp designs i think.

Didn't know about this - this looks much more FBP-like IMO.
 

I propose a challenge that illustrates the problem with fine grained componentry, and it is FizzBuzz. http://en.wikipedia.org/wiki/Fizz_buzz

This simple problem is supposedly used to test candidates on extremely basic programming ability. Solving this kind of problem with fbp and fine grained components like modulus, joining strings, etc, is really time consuming and brittle. A task you can complete in your language of choice in a minute.

Can you ( anybody in the mailing list ) implement this with general pourpose components in a clear and maintainable way with little effort? I'd like to see it.

I think we are in agreement here...  It doesn't look to me as if FizzBuzz would gain much from somehow being forced into an FBP mode.  It's basically one loop, and you have to keep the output in the same sequence, so you can't afford to split the flow on any of the decisions.  So I think you will land up using a "string of pearls" structure, where each pearl is something like "receive number; if x is true, emit y, send number".  I am appending a picture below...

On a related note, an educational component library for noflo could serve as a tool to teach kids and grown ups alike, similar to what logo did for procedural programming, or other similar efforts involving a simple robot like entity that moves around the screen and picks up objects, etc.

I was considering some sort of imaginary factory that the user has to build and or edit to produce the required goods, in a game like environment. Connecting machines together, getting requests from clients, shipments for parts, etc. What do you think ?

Sounds great!

Paul

[Tom Young]

I think something like this might do it.

(GenNumbers 1-100) -> (DivisibleBy 3)yes ->(Bizz) ->(A:DivisibleBy 7)yes->(Buzz)

                                          (DivisibleBy 3)no   ->(B:DivisibleBy 7)yes->(Buzz)

                                                                              (B:DivisibleBy 7)no  ->(ShowNumber)

Reminds me of the old flowcharting days.

-twy

Thomas W. Young, Founding Member
Stamford Data, LLC
47 Mitchell Street, Stamford,  CT  06902
Phone: (203)539-1278
Email: TomY...@stamforddata.com

On Sat, Mar 15, 2014 at 3:23 PM, Alfredo Sistema <sistemas...@gmail.com> wrote:

[Paul Morrison]

On Saturday, March 15, 2014 10:26:23 PM UTC-4, Matthew Lai wrote:

 

For those who remember the old FBP website, does the bouncing ball animation ring a bell?

Thanks for reminding me about the "bouncing ball" - I assume you mean this one: the nice chap who redesigned the FBP web site couldn't figure out how to fit it in... :-)   It's only a GIF file, but I think it conveys the idea...
 

[Paul Morrison]

On Saturday, March 15, 2014 11:13:23 PM UTC-4, Tom Young wrote:

I think something like this might do it.

(GenNumbers 1-100) -> (DivisibleBy 3)yes ->(Bizz) ->(A:DivisibleBy 7)yes->(Buzz)

                                          (DivisibleBy 3)no   ->(B:DivisibleBy 7)yes->(Buzz)

                                                                              (B:DivisibleBy 7)no  ->(ShowNumber)

Reminds me of the old flowcharting days.

In classical FBP your diagram as shown will result in the 3 output streams being intermixed randomly.  However, we could tag the output IPs with the relevant number, and then sort the output back into sequence...  That ought to work! 

[Tom Young]

Interesting, Paul.   As you say, the output order is indeterminate, but  is that a requirement?  Probably, for this example, but

maybe not in general, for real world problems.   If output order is required, we just add another merge component.   Nice! All we need is a component to fit each of the requirements, instead of a monolith to fit all the requirements.

  [I should have Fizz instead of Bizz, and Divisible by 5 instead of 7.]

Played this game in Japanese a long time ago:  ichi, nee, bizz, shee, buzz, bizz, ... 

      Regards,
 

                   -twy

Thomas W. Young, Founding Member
Stamford Data, LLC
47 Mitchell Street, Stamford,  CT  06902
Phone: (203)539-1278
Email: TomY...@stamforddata.com

--

[sistemas...@gmail.com]

Hello Thomas, the requirement is to output in order and write fizzbuzz when it's a multiple of 3 and 5, plus a new line after the result. Paul missed that one but it's easy to fix with a 'new line' component after or before the counter is increased.
My point is illustrated, such level of granularity is unwieldy and degrades into flowcharts with synchronization problems.
-- Mensaje original --
Desde: stamfo...@twyoung.com
Enviados: 16.03.2014 12:42
Para: flow-based-...@googlegroups.com
Asunto: Re: Post about Asynchronous Thinking

[Matthew Lai]

On Sunday, 16 March 2014 11:05:12 UTC-4, Paul Morrison wrote:

Thanks for reminding me about the "bouncing ball" - I assume you mean this one: the nice chap who redesigned the FBP web site couldn't figure out how to fit it in... :-)   It's only a GIF file, but I think it conveys the idea...

Yes, the GIF file was the one I had in mind. Small and simple example, which conveys the async
aspect of FBP very well too.

I just copied your idea and extended it with 9 interconnected blocks and had 3 coloured messages
(not balls, since if I show bouncing balls I may give folks the impression that "FBP has balls....". I like that
catch phrase even though it may be a bit gender biased).

To really showcase the bounded buffer FIFO capability one can start with 30 message IPs. Since
there are 9 blocks present the remaining 21 IPs will be queued up in the FIFOs. I know JavaFBP
can handle this, bounded buffer FIFO and fully loopback connection.

Yours,

Matt

 

[Raoul Duke]

http://sites.uclouvain.be/blog-ingi/2011/12/making-concurrency-easy-with-deterministic-dataflow/
:-)

[Raoul Duke]

> But I usually get the "wow" look from the folks interviewing me :)

not to be a jerk (but i guess i am a jerk) but i think that mostly
just means they don't know very much; people who are into animation
(e.g. games) would be worried about how do you control the system so
that e.g. only red shows at 3 seconds after the start, or they all
merge on top of each other after 10 seconds, or whatever else
*artistic* and *planned* thing should happen -- even if there is fun
randomness *otherwise* to make it look good and take the labor off the
back of the programmer to script each and every millisecond. so a tool
that is utterly random isn't much help. $0.02.

[Matthew Lai]

On Monday, 17 March 2014 18:01:16 UTC, raould wrote:

> But I usually get the "wow" look from the folks interviewing me :)

not to be a jerk (but i guess i am a jerk)

You are not alone! That makes two of us :)
 

but i think that mostly
just means they don't know very much; people who are into animation
(e.g. games)

Oh this is not about animation my friend. I only use minimal
animation to show the IP flow.
 

would be worried about how do you control the system so
that e.g. only red shows at 3 seconds after the start,

No. Red "hello world" is always visible unless another
IP is in front of it in the per inport bounded buffer FIFO.
 

or they all
merge on top of each other after 10 seconds,

Possible i.e. by chance all 3 "hello world" IPs go to the
same node, say the middle one. Then two will be waiting
in the inports while one will be displayed for 0.5sec.
 

or whatever else
*artistic* and *planned* thing should happen

Not planned, and certainly not artistic :)
The three "hello world" just moves around forever.
 

-- even if there is fun
randomness *otherwise* to make it look good and take the labor off the
back of the programmer to script each and every millisecond. so a tool
that is utterly random isn't much help. $0.02

Thanks for your two cents, but really the demo is worth less, probably $0.00 haha!

I believe I did mention this short demo does not do much except to showcase
the async aspect of the FBP. For the real hitters that do real work please refer
to the attached graphs. I went through the second one in the last FBP meetup.

So raould, can you share with us your own favourite FBP application that showcases
the async capability of FBP? I said this before, and I say it here again: use FBP to
solve a real life problem that affects YOU. Yes YOU yourself! Until YOU do that
there is no buy in from you. If there is no buy in from you then why bother to spend
time with FBP? I don't care whether it is JavaFBP or NoFlo or GoFlow or whatever,
as long as it incorporates FBP ideas (ok, with lots of async stuff that can utilize
the multiple cores).

Matt

[Raoul Duke]

>> but i think that mostly
>> just means they don't know very much; people who are into animation
>> (e.g. games)
> Oh this is not about animation my friend. I only use minimal
> animation to show the IP flow.

i think i'm not doing a good job saying what i mean. :-)

what i mean is, not about the fbp graphical tool. i mean about how do
you sell fbp, and impress somebody or more importantly really prove it
is good, not just impress with "now how much would you pay" whizz bang
dog and pony.

each target person probably has a different background, different
needs, etc. so for some people the demo you have is cool and does the
job. for other people -- these are what i'm trying to get at -- it is
more of a "so what" since it appears to be generating uncontrollable
behaviour.

> So raould, can you share with us your own favourite FBP application that showcases
> the async capability of FBP? I said this before, and I say it here again: use FBP to
> solve a real life problem that affects YOU. Yes YOU yourself! Until YOU do that
> there is no buy in from you. If there is no buy in from you then why bother to spend
> time with FBP? I don't care whether it is JavaFBP or NoFlo or GoFlow or whatever,
> as long as it incorporates FBP ideas (ok, with lots of async stuff that can utilize
> the multiple cores).

yes and no. :-) at least i sure hope not everybody takes your stance
like that, although i do not think you are disallowed to take such a
stance.

sincerely.

[Matthew Lai]

On Monday, 17 March 2014 19:42:31 UTC, raould wrote:

>> but i think that mostly
>> just means they don't know very much; people who are into animation
>> (e.g. games)
> Oh this is not about animation my friend. I only use minimal
> animation to show the IP flow.

i think i'm not doing a good job saying what i mean. :-)

That makes the two of us too, again :)

what i mean is, not about the fbp graphical tool. i mean about how do
you sell fbp, and impress somebody or more importantly really prove it
is good, not just impress with "now how much would you pay" whizz bang
dog and pony.

If I cannot impress myself by solving a real life problem that really matters,
how can I impress someone else?

I want to prove FBP solution is unique; there are too many good solutions out there.
Ever heard of unique selling point (USP)?

Open source, no need to pay. Tcl/Tk is open source.
 

each target person probably has a different background, different
needs, etc. so for some people the demo you have is cool and does the
job. for other people -- these are what i'm trying to get at -- it is
more of a "so what" since it appears to be generating uncontrollable
behaviour.

The other attached graphs generate controllable, async behaviours :)

I am too lazy to explain the other two. Me bad. I did go through one
in the meetup!
 

> So raould, can you share with us your own favourite FBP application that showcases
> the async capability of FBP? I said this before, and I say it here again: use FBP to
> solve a real life problem that affects YOU. Yes YOU yourself! Until YOU do that
> there is no buy in from you. If there is no buy in from you then why bother to spend
> time with FBP? I don't care whether it is JavaFBP or NoFlo or GoFlow or whatever,
> as long as it incorporates FBP ideas (ok, with lots of async stuff that can utilize
> the multiple cores).

yes and no.

Care to share the "yes" part?
 

:-) at least i sure hope not everybody takes your stance
like that, although i do not think you are disallowed to take such a

stance;

 

A strong stance is what make me stick with FBP for the last 12 years.
I am biased as usual :)

Matt

[Raoul Duke]

> The other attached graphs generate controllable, async behaviours :)
>
> I am too lazy to explain the other two. Me bad. I did go through one
> in the meetup!

ok thanks, that's great to hear, i think that's a good thing to use to
"sell" fbp.

>> yes and no.
> Care to share the "yes" part?

i only meant that i agree & disagree with your stance.

i have not done FBP work. i have used erlang, clojure, haskell, and a
little bit of gpars, none "in anger" as the kids on my lawn might say,
only for small time personal edification.

[Alfredo Sistema]

Matthew, you mention your tcl/tk implementation of FBP often, i'd like to know more about it, did you make a blog post about it or something ? I'd like to have fun porting your system to perl.

--

[Matthew Lai]

On Monday, 17 March 2014 16:32:20 UTC-4, raould wrote:

> The other attached graphs generate controllable, async behaviours :)
>
> I am too lazy to explain the other two. Me bad. I did go through one
> in the meetup!

ok thanks, that's great to hear, i think that's a good thing to use to
"sell" fbp.

I always sell "FBP" whenever I have job interviews :)
Problem was, both me and the interviewers spent all the time on talking
about FBP and very little time on the actual job position itself...

>> yes and no.
> Care to share the "yes" part?

i only meant that i agree & disagree with your stance.

i have not done FBP work. i have used erlang, clojure, haskell, and a
little bit of gpars, none "in anger" as the kids on my lawn might say,
only for small time personal edification.

Erlang is the "king" of event processing I was once told in the Tcl Wiki.
Dumb question: how is the event processing engine in Erlang compared
to node.js?

Matt

[Matthew Lai]

Alfredo,

How's the support for event processing and TCP socket in Perl?
I make heavy use of non blocking async I/O event processing and model
all inports as socket ports. Just don't know if these would present a big
hurdle for the porting.

I have everything under CVS in my local hard drive. Can give you a tar
file if you are comfortable with Unix/Linux platform.

Yours,

Matt

[Paul Morrison]

On Mon, Mar 17, 2014 at 11:12 PM, Matthew Lai <mm...@sympatico.ca> wrote:

Erlang is the "king" of event processing I was once told in the Tcl Wiki.
Dumb question: how is the event processing engine in Erlang compared
to node.js?

I am sure other people are more qualified to comment on Erlang, but I do know that it supports large numbers of parallel, relatively short-lived, processes, which are oriented towards supporting multiple phone calls.  I have heard Erlang's processes described as "green processes" (rather than "green threads") - apparently, given this orientation, performance is very good!

You might be interested in looking at Joe Armstrong's research suggestions, posted on the old FBP Wiki (2009) -

http://www.jpaulmorrison.com/cgi-bin/wiki.pl?JoeArmstrongsResearchSuggestions

Paul M

[Alfredo Sistema]

Maybe the term port was badly chosen, i have no experience with Tcl, but i'd like to know the architecture and techniques you used, and if feasible make a perl version for the fun of it ( and massive module ecosystem ).

--

[Amirouche Boubekki]

On Saturday, March 1, 2014 4:57:18 AM UTC+1, Alfredo wrote:

http://scriptogr.am/alfredo/post/asynchronous-thinking

Please speak your mind in this thread.

Too long, did not watch. That said I quick-read the text.

Why not introduce asynchronous code with a "merge" object: «fire a callback, when all other callbacks are fired» here is an implementation that might be working http://dpaste.com/1744641

- no need for lock
- parallel execution of code

Just discovered this forum and flow programming. Looks interesting.

[Matthew Lai]

On Tuesday, 18 March 2014 22:07:45 UTC, Alfredo wrote:

Maybe the term port was badly chosen, i have no experience with Tcl, but i'd like to know the architecture and techniques you used, and if feasible make a perl version for the fun of it ( and massive module ecosystem ).

Oh, I sort of described the runtime environment in the last Toronto meetup.
Give me a few days to capture the info into a prezi presentation so that anyone interested
can take a look there.

As for techniques, they are all antique, 1996-style really. In a nutshell:

- Each node in the FBP graph corresponds to a Linux (or Windows) stand alone process.

- Each process is single threaded.

- Each inport on a node corresponds to a TCP socket. In Tcl jargon it is called a listening
  server socket.

- Each outport on a node is also a TCP socket, but it sends IPs out only.

- Two types of process:
  (a) process that runs in non read-blocking async I/O (inports) and write blocking (outports)
  (b) process that runs in non blocking async I/O (inports and outports)

  The (a) type corresponds to almost all the nodes in the FBP graph.

  The (b) type corresponds to (i) the load balancer node and (ii) the traffic cop node.

  Traffic cop node is invisible to the user. It is the kludge that I use to implement
  bounded buffer FIFO for all the inports on all the nodes. The traffic cop is per FBP network
  per computer. That is, if there are 3 separate FBP networks running on my ultrabook
  machine, then there will be 3 separate traffic cop nodes running, one for each network.

- Each node has an extra admin port. The admin port is used for startup/info query/shutdown
  sequencing.

- Each computer has a daemon process, fbp_agent, running which coordinates with the
  Tk-based FBP GUI to create/maintain/shutdown the FBP network(s). The fbp_agent spawns
  the individual processes, then communicates with the admin port of those processes for
  subsequent startup operations. Once startup is finished the fbp_agent is not involved in the
  process outport to process inport communication.

That's it. The framework is simple enough to run on any machine that can launch Tcl (old
1996 computer, fast ultrabook, small Raspberry Pi, and "potentially" Android since Tcl folks
manage to get a Tcl build on Android working as of Dec 2013). This framework deviates
from traditional FBP though

- no IIP support
- no bracket IP
- no subnet support
- cannot handle selective port read i.e. collate component not available
- and may be a million other stuff...

But I like its simplicity, does what I really need it to do (financial data ETL and
give old computers a second life).

So I'm a happy camper :)

Matt

P.S. When my prezi is ready I'll let you know.

[Paul Morrison]

On Wednesday, March 19, 2014 at 1:54:23 PM UTC-4, Matthew Lai wrote:

    The (b) type corresponds to (i) the load balancer node and (ii) the traffic cop node.

 
Minor quibble here - the load balancer does do something slightly illegal, but I think it's a different illegal: it looks at the number of IPs currently in each of its downstream connections, to decide where to send the current IP,  but I can see why you spotted that it was abnormal!  :-)

 
P.S. When my prezi is ready I'll let you know.

Looking forward to it!

I have linked one of the jsfbp issues to this topic, Matt, it would be great if you could jump in - somewhere!  The issue is at https://github.com/jpaulm/jsfbp/issues/14 .

[Matthew Lai]

On Tuesday, 14 April 2015 20:32:24 UTC-4, Paul Morrison wrote:

On Wednesday, March 19, 2014 at 1:54:23 PM UTC-4, Matthew Lai wrote:

    The (b) type corresponds to (i) the load balancer node and (ii) the traffic cop node.

 
Minor quibble here - the load balancer does do something slightly illegal, but I think it's a different illegal: it looks at the number of IPs currently in each of its downstream connections, to decide where to send the current IP,  but I can see why you spotted that it was abnormal!  :-)

 No peeping downstream :)

The load balancer checks the "state" of its outports. If it is busy (i.e. an ACK/NAK has not been received) then another outport is checked,
until it finds an outport which is "free" or it just blocks, waiting for an outport to free up.

 
P.S. When my prezi is ready I'll let you know.

Looking forward to it!

Had been lazy... only managed to put up a few ppt slides to show the selective port read implementation in our last fbp meetup.
I believe the ppt is still in the meetup.com.

I have linked one of the jsfbp issues to this topic, Matt, it would be great if you could jump in - somewhere!  The issue is at https://github.com/jpaulm/jsfbp/issues/14 .

Don't have github account... I'll see what I can do.

Yours,

Matt