Cells compared to Flow-Based Programming

<shameless plug>

You might also be interested in Visual Frameworks(TM).

Here are two short papers about it:

http://www.visualframeworksinc.com/DEBS2007-paper63.pdf
http://www.visualframeworksinc.com/CCECE06-0379.pdf

(more info / slides at www.visualframeworksinc.com).

The current version is written in Lispworks (this version is a work in
progress). I'm open to ideas on how to move it forward.

</shameless plug>

pt

George Neuner wrote:

> You're also getting too caught up in the communication abstraction.
> The book's "information packets" are nothing more than the logical
> "wires" connecting the functional units of the application. It really
> doesn't matter whether the wiring is implemented using IPC messaging,
> in(ter)-process signaling, function callbacks, shared memory or actual
> wires.

It matters if you are addressing performance :-). Our VF technology is
similar to FBP (event-driven instead of IP's). We implemented and shipped
real products around 1995 on 8-bit 8051's with 32K of RAM (128K ROM). IPC
messaging, inter-process signalling, RTOS's, C, etc. were all non-starters.
The paradigm of "events" and "wires" made it possible to imagine and
implement a tiny kernel and full-blown applications (600-page spec,
resulting in about the equivalent of 300 "threads" iirc) on such stunted
hardware.

It also matters if you believe (like I do) that it is valuable to decompose
a paradigm into its most primitive elements.

pt

Frank Buss wrote:
> While trying to implement the telegram problem in FBP Lisp, this was
> exactly my feeling: You can concentrate on writing just one process, with
> explicit defined input and outputs. Then you can connect the components
> and the program just works (if you've tested the components before and the
> specification of the ports matches).

I think that what you are experiencing are the benefits of "encapsulation".

OOP apologists use "encapsulation" as a buzzword, but, IMO OOP does not
achieve encapsulation that is as good as that of "processes"
(multi-tasking, threads, whatever).

When you follow the rules of process-based programming, you do not scribble
outside of a process' boundaries. Your communication with other processes
is explicit and well-defined. Everything the process does is "visible at a
glance" (locality of reference).

OOP increases reuse, but breaks encapsulation through inheritance. It is
difficult to understand a set of methods of a class without also
understanding the methods of the ancestor(s) - hence, locality of
reference - one of the benefits of encapsulation - is broken by
inheritance.

The problem with processes is context-switch overhead. Ideally, you want to
push the paradigm down the lowest levels of the language, e.g. down to the
subroutine or statement level (e.g. each subroutine is a concurrent,
stand-alone unit). I.E. you want to architect your code with 100's,
1000's, 10,000's of "processes".

Cells, FBP, stackless python, my event-based stuff are variants of
process-based programming (reactive), with attempts to reduce the overhead
so that the reactive paradigm can be used at a fine grain.

pt

On Mon, 26 May 2008 12:18:34 -0400, Paul Tarvydas
<tarvydas@visualframeworksinc.com> wrote:

>George Neuner wrote:
>
>> You're also getting too caught up in the communication abstraction.
>> The book's "information packets" are nothing more than the logical
>> "wires" connecting the functional units of the application. It really
>> doesn't matter whether the wiring is implemented using IPC messaging,
>> in(ter)-process signaling, function callbacks, shared memory or actual
>> wires.
>
>It matters if you are addressing performance :-). Our VF technology is
>similar to FBP (event-driven instead of IP's). We implemented and shipped
>real products around 1995 on 8-bit 8051's with 32K of RAM (128K ROM). IPC
>messaging, inter-process signalling, RTOS's, C, etc. were all non-starters.
>The paradigm of "events" and "wires" made it possible to imagine and
>implement a tiny kernel and full-blown applications (600-page spec,
>resulting in about the equivalent of 300 "threads" iirc) on such stunted
>hardware.
>
>It also matters if you believe (like I do) that it is valuable to decompose
>a paradigm into its most primitive elements.

Of course performance matters. I was simply pointing out that the
implementation described in the book was only one particular way of
doing it and not to read too much into the method. The author himself
compared his IP abstraction to several other coordination methods
without really explaining why he felt IP was better.

George
--
for email reply remove "/" from address

On May 26, 9:30*pm, George Neuner <gneuner2/@/comcast.net> wrote:
> On Mon, 26 May 2008 12:18:34 -0400, Paul Tarvydas
>
>
>
>
>
> <tarvy...@visualframeworksinc.com> wrote:
> >George Neuner wrote:
>
> >> You're also getting too caught up in the communication abstraction.
> >> The book's "information packets" are nothing more than the logical
> >> "wires" connecting the functional units of the application. *It really
> >> doesn't matter whether the wiring is implemented using IPC messaging,
> >> in(ter)-process signaling, function callbacks, shared memory or actual
> >> wires.
>
> >It matters if you are addressing performance :-). *Our VF technology is
> >similar to FBP (event-driven instead of IP's). *We implemented and shipped
> >real products around 1995 on 8-bit 8051's with 32K of RAM (128K ROM). *IPC
> >messaging, inter-process signalling, RTOS's, C, etc. were all non-starters.
> >The paradigm of "events" and "wires" made it possible to imagine and
> >implement a tiny kernel and full-blown applications (600-page spec,
> >resulting in about the equivalent of 300 "threads" iirc) on such stunted
> >hardware.
>
> >It also matters if you believe (like I do) that it is valuable to decompose
> >a paradigm into its most primitive elements.
>
> Of course performance matters. *I was simply pointing out that the
> implementation described in the book was only one particular way of
> doing it and not to read too much into the method. *The author himself
> compared his IP abstraction to several other coordination methods
> without really explaining why he felt IP was better.
>
> George
> --
> for email reply remove "/" from address- Hide quoted text -
>
> - Show quoted text -

The main idea of the fbp is that you have processing centers linked
by routes where IP moves.
Lets' start with a dumb idea . We have a function called double :
(defun double (x) (* 2 x))
Now we design a processing center like this :
(make-center #'double)
=> double-center-1

Now we have our program is just defining a path of links .

(path user-input double-center-1 print-center)

Note that we don't call the functions. Data just moves on it's way.
To spice things a little bit add few more programs
(path double-center-1 inverse mod print-center)

And this one:
(path double-center double-center print-center)

Theer is no need calling anything, no spawning processes etc. All our
job is to define path. The ip knows which path they belong. So they
move along the path. The processing center knows what path send them
those ips so it sends the result ips on the same path. That's it.
Everything else is just an implementation technique.
While explicit paralelization could find itself in the function level,
in the path level everything is implicitly paralel.

Slobodan Blazeski wrote:
> On May 26, 9:30 pm, George Neuner <gneuner2/@/comcast.net> wrote:
>
>>On Mon, 26 May 2008 12:18:34 -0400, Paul Tarvydas
>>
>>
>>
>>
>>
>><tarvy...@visualframeworksinc.com> wrote:
>>
>>>George Neuner wrote:
>>
>>>>You're also getting too caught up in the communication abstraction.
>>>>The book's "information packets" are nothing more than the logical
>>>>"wires" connecting the functional units of the application. It really
>>>>doesn't matter whether the wiring is implemented using IPC messaging,
>>>>in(ter)-process signaling, function callbacks, shared memory or actual
>>>>wires.
>>
>>>It matters if you are addressing performance :-). Our VF technology is
>>>similar to FBP (event-driven instead of IP's). We implemented and shipped
>>>real products around 1995 on 8-bit 8051's with 32K of RAM (128K ROM). IPC
>>>messaging, inter-process signalling, RTOS's, C, etc. were all non-starters.
>>>The paradigm of "events" and "wires" made it possible to imagine and
>>>implement a tiny kernel and full-blown applications (600-page spec,
>>>resulting in about the equivalent of 300 "threads" iirc) on such stunted
>>>hardware.
>>
>>>It also matters if you believe (like I do) that it is valuable to decompose
>>>a paradigm into its most primitive elements.
>>
>>Of course performance matters. I was simply pointing out that the
>>implementation described in the book was only one particular way of
>>doing it and not to read too much into the method. The author himself
>>compared his IP abstraction to several other coordination methods
>>without really explaining why he felt IP was better.
>>
>>George
>>--
>>for email reply remove "/" from address- Hide quoted text -
>>
>>- Show quoted text -
>
>
> The main idea of the fbp is that you have processing centers linked
> by routes where IP moves.
> Lets' start with a dumb idea . We have a function called double :
> (defun double (x) (* 2 x))
> Now we design a processing center like this :
> (make-center #'double)
> => double-center-1
>
> Now we have our program is just defining a path of links .
>
> (path user-input double-center-1 print-center)
>
> Note that we don't call the functions. Data just moves on it's way.
> To spice things a little bit add few more programs
> (path double-center-1 inverse mod print-center)
>
> And this one:
> (path double-center double-center print-center)
>
> Theer is no need calling anything,...

Looks like calls to me, if I am the one laying out the path:

(print-center (double-center (double-center <input>)))

Change it to smalltalk and "send messages" and you still have the same
paradigm: programmer-centric hand-implementd hard-wired dataflow, and
wham yer dead.

kt



--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

On May 24, 3:17*pm, "Alex Mizrahi" <udode...@users.sourceforge.net>
wrote:
> *FB> FBP is very different:
>
> from what you describe it's different only terminologically..
>
> *FB> *When developing applications, you start with defining information
> *FB> packets (IP). In Lisp an IP could be a hashtable or any other Lisp
> *FB> object.
>
> so IP is just a fancy way to say "any object"? maybe it matter for
> distributed
> implementations, where IPs have to be serializable
>
> *FB> *Then you define some processes and interconnect them. A process has
> *FB> inputs and outputs for processing IPs. The process itself is a program,
> *FB> with local storage. A process can be instantiated multiple times and
> *FB> can be configured with configuration IPs (there are preemptive and
> *FB> cooperative multitasking implementations).
>
> in Cells terminology, process is model (class), process instance is an
> object,
> interconnect is synapse.
>
> *FB> The main motivation of FBP is to reuse stable and tested processes for
> *FB> many applications.
>
> so is OOP, and articles you've linked say that OOP is quite related to FBP
>
> *FB> I think Cells is more fine granular: there are not a few connected
> black
> *FB> boxes, but a network of connected values.
>
> in other words, Cells doesn't hide guts of processes from you, right?
>
> *FB> better, maybe this depends on the application. But I think every Cells
> *FB> network can be transformed to a FBP-like network, but the other
> *FB> direction would be more difficult, so FBP may be a more general
> *FB> concept.
>
> for my untrained eye Cells seems to be like a particular implementation of
> FBP concepts. can you show an example what general FBP can do
> but Cells can't?

Cells looks to me more like event driven than dataflow concept.
Dataflow reoves the micromanagement of function calls.When data
arrives it gets processed.
Imagine managing a restoraunt:
In traditional programming you'll have to tell the employees what to
do.
Jim get some meat. Mary serve table 23. Cory clean the floor. Dru make
lazagna etc.
So you have to take care of coordination between the,
In dataflow you just specify the rules.
Mary you're the waitress whenever customers arrive pick their orders
and give it chef.
Dru you're the chef, whenever you get orders prepare the food ordered.
whever you miss some ingredient give an order to Jim
Jim you're the supplier. Whenever you get an order from the chef go
buy it.
So if you have a bottleneck in the kitchen you just add another chef.
Paralelism goes (almost) for free.

On May 27, 4:20*pm, Ken Tilton <kennytil...@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On May 26, 9:30 pm, George Neuner <gneuner2/@/comcast.net> wrote:
>
> >>On Mon, 26 May 2008 12:18:34 -0400, Paul Tarvydas
>
> >><tarvy...@visualframeworksinc.com> wrote:
>
> >>>George Neuner wrote:
>
> >>>>You're also getting too caught up in the communication abstraction.
> >>>>The book's "information packets" are nothing more than the logical
> >>>>"wires" connecting the functional units of the application. *It really
> >>>>doesn't matter whether the wiring is implemented using IPC messaging,
> >>>>in(ter)-process signaling, function callbacks, shared memory or actual
> >>>>wires.
>
> >>>It matters if you are addressing performance :-). *Our VF technology is
> >>>similar to FBP (event-driven instead of IP's). *We implemented and shipped
> >>>real products around 1995 on 8-bit 8051's with 32K of RAM (128K ROM). *IPC
> >>>messaging, inter-process signalling, RTOS's, C, etc. were all non-starters.
> >>>The paradigm of "events" and "wires" made it possible to imagine and
> >>>implement a tiny kernel and full-blown applications (600-page spec,
> >>>resulting in about the equivalent of 300 "threads" iirc) on such stunted
> >>>hardware.
>
> >>>It also matters if you believe (like I do) that it is valuable to decompose
> >>>a paradigm into its most primitive elements.
>
> >>Of course performance matters. *I was simply pointing out that the
> >>implementation described in the book was only one particular way of
> >>doing it and not to read too much into the method. *The author himself
> >>compared his IP abstraction to several other coordination methods
> >>without really explaining why he felt IP was better.
>
> >>George
> >>--
> >>for email reply remove "/" from address- Hide quoted text -
>
> >>- Show quoted text -
>
> > The main idea of the fbp is that you have *processing centers linked
> > by routes where IP moves.
> > Lets' start with a dumb idea . We have a function called double :
> > (defun double (x) (* 2 x))
> > Now we design a processing center like this :
> > (make-center #'double)
> > => double-center-1
>
> > Now we have our program is just defining a path of links .
>
> > (path user-input double-center-1 print-center)
>
> > Note that we don't call the functions. Data just moves on it's way.
> > To spice things a little bit add few more programs
> > (path *double-center-1 inverse mod print-center)
>
> > And this one:
> > (path double-center *double-center print-center)
>
> > Theer is no need *calling anything,...
>
> Looks like calls to me, if I am the one laying out the path:
>
> (print-center (double-center (double-center <input>)))
>
> Change it to smalltalk and "send messages" and you still have the same
> paradigm: programmer-centric hand-implementd hard-wired dataflow, and
> wham yer dead.
You are right but how does cells solve this?
>
> kt
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
> ECLM rant:http://video.google.com/videoplay?do...93764413&hl=en
> ECLM talk:http://video.google.com/videoplay?do...2928&q=&hl=en- Hide quoted text -
>
> - Show quoted text -

Slobodan Blazeski wrote:
> On May 24, 3:17 pm, "Alex Mizrahi" <udode...@users.sourceforge.net>
> wrote:
>
>> FB> FBP is very different:
>>
>>from what you describe it's different only terminologically..
>>
>> FB> When developing applications, you start with defining information
>> FB> packets (IP). In Lisp an IP could be a hashtable or any other Lisp
>> FB> object.
>>
>>so IP is just a fancy way to say "any object"? maybe it matter for
>>distributed
>>implementations, where IPs have to be serializable
>>
>> FB> Then you define some processes and interconnect them. A process has
>> FB> inputs and outputs for processing IPs. The process itself is a program,
>> FB> with local storage. A process can be instantiated multiple times and
>> FB> can be configured with configuration IPs (there are preemptive and
>> FB> cooperative multitasking implementations).
>>
>>in Cells terminology, process is model (class), process instance is an
>>object,
>>interconnect is synapse.
>>
>> FB> The main motivation of FBP is to reuse stable and tested processes for
>> FB> many applications.
>>
>>so is OOP, and articles you've linked say that OOP is quite related to FBP
>>
>> FB> I think Cells is more fine granular: there are not a few connected
>>black
>> FB> boxes, but a network of connected values.
>>
>>in other words, Cells doesn't hide guts of processes from you, right?
>>
>> FB> better, maybe this depends on the application. But I think every Cells
>> FB> network can be transformed to a FBP-like network, but the other
>> FB> direction would be more difficult, so FBP may be a more general
>> FB> concept.
>>
>>for my untrained eye Cells seems to be like a particular implementation of
>>FBP concepts. can you show an example what general FBP can do
>>but Cells can't?
>
>
> Cells looks to me more like event driven than dataflow concept.

I am reminded of the four blind men analyzing an elephant. If You People
Actually Used these things you would know what they are and not be
falling back on useless analogies.

Events are hard for Cells, change is easy/

> Dataflow reoves the micromanagement of function calls.When data
> arrives it gets processed.
> Imagine managing a restoraunt:

Yeah!!!! Argument from analogy!

> In traditional programming you'll have to tell the employees what to
> do.
> Jim get some meat. Mary serve table 23. Cory clean the floor. Dru make
> lazagna etc.
> So you have to take care of coordination between the,
> In dataflow you just specify the rules.

Which is the exact same thing as traditional programming... well, know,
it is worse. Try Prolog ot constraints or any non-deterministic (name
well chosen) paradigm.

> Mary you're the waitress whenever customers arrive pick their orders
> and give it chef.
> Dru you're the chef, whenever you get orders prepare the food ordered.
> whever you miss some ingredient give an order to Jim
> Jim you're the supplier. Whenever you get an order from the chef go
> buy it.
> So if you have a bottleneck in the kitchen you just add another chef.

The problem Brooks identified in NSB was not handling more data of the
same kind, it was handling increasing numbers of kinds of data and the
combinatorial explosion of dependencies arising therefrom. The problem
is not more customers, the problem is adding a casino to the restaurant
and then entertainment and then getting food to the showgirls between acts.

> Paralelism goes (almost) for free.

That would be the chorus line. Yes, it's free, they make it up on the slots.

hth, kenny

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

On May 27, 4:54*pm, Ken Tilton <kennytil...@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On May 24, 3:17 pm, "Alex Mizrahi" <udode...@users.sourceforge.net>
> > wrote:
>
> >> FB> FBP is very different:
>
> >>from what you describe it's different only terminologically..
>
> >> FB> *When developing applications, you start with defining information
> >> FB> packets (IP). In Lisp an IP could be a hashtable or any other Lisp
> >> FB> object.
>
> >>so IP is just a fancy way to say "any object"? maybe it matter for
> >>distributed
> >>implementations, where IPs have to be serializable
>
> >> FB> *Then you define some processes and interconnect them. A process has
> >> FB> inputs and outputs for processing IPs. The process itself is a program,
> >> FB> with local storage. A process can be instantiated multiple times and
> >> FB> can be configured with configuration IPs (there are preemptive and
> >> FB> cooperative multitasking implementations).
>
> >>in Cells terminology, process is model (class), process instance is an
> >>object,
> >>interconnect is synapse.
>
> >> FB> The main motivation of FBP is to reuse stable and tested processes for
> >> FB> many applications.
>
> >>so is OOP, and articles you've linked say that OOP is quite related to FBP
>
> >> FB> I think Cells is more fine granular: there are not a few connected
> >>black
> >> FB> boxes, but a network of connected values.
>
> >>in other words, Cells doesn't hide guts of processes from you, right?
>
> >> FB> better, maybe this depends on the application. But I think every Cells
> >> FB> network can be transformed to a FBP-like network, but the other
> >> FB> direction would be more difficult, so FBP may be a more general
> >> FB> concept.
>
> >>for my untrained eye Cells seems to be like a particular implementation of
> >>FBP concepts. can you show an example what general FBP can do
> >>but Cells can't?
>
> > Cells looks to me more like event driven than dataflow concept.
>
> I am reminded of the four blind men analyzing an elephant. If You People
> Actually Used these things you would know what they are and not be
> falling back on useless analogies.
>
> Events are hard for Cells, change is easy/
>
> > Dataflow reoves the micromanagement of function calls.When data
> > arrives it gets processed.
> > Imagine managing a restoraunt:
>
> Yeah!!!! Argument from analogy!
>
> > In traditional programming you'll have to tell the employees what to
> > do.
> > Jim get some meat. Mary serve table 23. Cory clean the floor. Dru make
> > lazagna etc.
> > So you have to take care of coordination *between the,
> > In dataflow you just specify the rules.
>
> Which is the exact same thing as traditional programming... well, know,
> it is worse. Try Prolog ot constraints or any non-deterministic (name
> well chosen) paradigm.
>
> > Mary you're the waitress whenever customers arrive pick their orders
> > and give it chef.
> > Dru you're the chef, whenever you get orders prepare the food ordered.
> > whever you miss some ingredient give an order to Jim
> > Jim you're the supplier. Whenever you get an order from the chef go
> > buy it.
> > So if you have a bottleneck in the kitchen you just add another chef.
>
> The problem Brooks identified in NSB was not handling more data of the
> same kind, it was handling increasing numbers of kinds of data and the
> combinatorial explosion of dependencies arising therefrom. The problem
> is not more customers, the problem is adding a casino to the restaurant
> and then entertainment and then getting food to the showgirls between acts..
>
> > Paralelism goes (almost) for free.
>
> That would be the chorus line. Yes, it's free, they make it up on the slots.
>
> hth, kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
> ECLM rant:http://video.google.com/videoplay?do...93764413&hl=en
> ECLM talk:http://video.google.com/videoplay?do...2928&q=&hl=en- Hide quoted text -
>
> - Show quoted text -
Ok you got me. Any idea for cool problem with cells? Pure cells only
no gui crap please.