What makes a FBP component more resuable/maintainable than JavaScript API?

[Giant Elk]

Hi,

What makes a FBP component more reusable/maintainable than a well written JavaScript API?

[Paul Tarvydas]

On Nov 2, 2015, at 9:28 PM, Giant Elk <flyinghor...@gmail.com> wrote:

Hi,

What makes a FBP component more reusable/maintainable than a well written JavaScript API?

Asynchrony.

pt

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

[Giant Elk]

Can you elaborate on Asynchrony... MeteorJS has Asynchronous functions, but not FBP. And what about apps that don't need Asynchronous stuff?

- GE

[Paul Morrison]

Hopefully this will become clearer once you have read (the first half of) the book!  I am trying to get people away from the old von Neumann image of a program (single hierarchy of routines linked by "call"s) to something more like an assembly line of machines/processors with the work objects travelling across conveyor belts between them.  Think of a soft-drink bottling factory - see slide 7 of http://www.jpaulmorrison.com/fbp/FBPnew.ppt . 

Asynchronism/asynchrony comes in because all these machines are running concurrently, so "call" is not the right linkage mechanism - send/receive is and, as Gelernter (Linda) points out, "call" can be easily simulated using send/receive.

HTH,

Paul

--