Cells compared to Flow-Based Programming

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.

I already did that. Reminds me of the Russian joke:

I'm very ill.
Try drugs.
Tried. Ain't work.
Try herbas.
Tried. Ain't work.
Try surgery.
Tried. Ain't work.

Then pray to god
Tried. Ain't work.

Slobodan Blazeski wrote:
> 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.

Let's turn that around, that question still has the tool in front: what
applications (or libraries -- AC is having fun with a Web programming
library built on Cells) do you consider cool?

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

Slobodan Blazeski wrote:
> 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?

Imagine you have been asked to write a report program that will take in
all the financial data for a company for last year and print out monthly
totals for revenue, costs, taxes, etc etc with subtotals etc, totalling
each for the year, computing a bottomline by month and then for the
whole year.

You have a great idea. Work out how to import the raw data into
VisiCalc. How would VisiCalc solve that?

Hint: it will /not/ involve you looking at the VisiCalc columns and rows
thinking "OK, the data starts here in A1 then flows over to B12 then
jumps out to C7 and D9". That is push, Visicalc is pull and really just
declarative: B12 = A1 + 42. I do not think about "pulling" from A1, I
just think about computing B12. The flow is an emergent property, not
part of my thinking.

The neat thing is that you can now add columns for new months and watch
results pile up if you can get a real-time feed out of the CFO, and as
they make corrections to last year's data....

With Cells you stop to think how to solve your problem as if your
application were a spreadseet model. In RoboCup, a first order set of
Cells took raw feeds from the server (which is simulated sensory data,
so we have some work to do just to build a "mental model" of where we
are on the field and where everything is) and, well, computed just that,
a model of the field, players, goals, and ball. Now I know where I am
and in what direction lies the ball etc etc.

The next layer of Cells decided on a strategy (the goalie might decide
to position themself ideally between the ball and goal until a shot is
taken (a higher order result), at which point the strategy rule should
recompute a new strategy: catch the ball. (Hmmm, I should have had it
consider tipping the ball over the goal or just clearing it.)

The strategy instance computes a series of "tactics" -- steps to take to
achieve the strategy. Each tactic had a rule to decide when it had been
achieved, or when it should be abandoned.

The cool thing is that I am in a game with twenty-one other players so I
can be in the middle of dribbling the ball downfield when my next sight
input arrives and the worldview cells rerun and suddenly the rule to
decide whether or not it is time to tap the ball suddenly gets back NIL
for position of ball -- it has gone out of sight -- and with luck I have
allowed for that and my design either drops back to tactic "find ball"
or as the designer I have had the foresight to code up the "abandon"
rule on the dribble strategy to go to true if I can no longer even see
the ball -- I mean, what's the point, right? (OK, OK, I know, this is
just an example, a real footballer does not need to see the ball
continuously, no quibbling plz <g>.) But in any case it is all
declarative. I cannot think about /particular/ events because the rules
I write must work for all circumstances as long as the instance I am
serving is alive. I decide what happens in /any/ event, or better, for
any state of the surrounding world, specifically the state that matters
to this slot being calculated by this rule.

Look, it is a new paradigm, OK? Old if you count VisiCalc, but then it
may as well be from Mars because we programmers have been hand-animating
our models for fifty years and cannot imagine an application built in
the mindset of CFO playing with VisiCalc. It took me a solid year to let
go of the hand-animation habit even after falling in love with Cells,
just to let you know how deep is the habit.

kzo

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

Ken Tilton wrote:
>
>
> Slobodan Blazeski wrote:
>
>> 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?
>
>
> Imagine you have been asked to write a report program that will take in
> all the financial data for a company for last year and print out monthly
> totals for revenue, costs, taxes, etc etc with subtotals etc, totalling
> each for the year, computing a bottomline by month and then for the
> whole year.
>
> You have a great idea. Work out how to import the raw data into
> VisiCalc. How would VisiCalc solve that?
>
> Hint: it will /not/ involve you looking at the VisiCalc columns and rows
> thinking "OK, the data starts here in A1 then flows over to B12 then
> jumps out to C7 and D9". That is push, Visicalc is pull and really just
> declarative: B12 = A1 + 42. I do not think about "pulling" from A1, I
> just think about computing B12. The flow is an emergent property, not
> part of my thinking.
>
> The neat thing is that you can now add columns for new months and watch
> results pile up if you can get a real-time feed out of the CFO, and as
> they make corrections to last year's data....
>
> With Cells you stop to think how to solve your problem as if your
> application were a spreadseet model. In RoboCup, a first order set of
> Cells took raw feeds from the server (which is simulated sensory data,
> so we have some work to do just to build a "mental model" of where we
> are on the field and where everything is) and, well, computed just that,
> a model of the field, players, goals, and ball. Now I know where I am
> and in what direction lies the ball etc etc.
>
> The next layer of Cells decided on a strategy (the goalie might decide
> to position themself ideally between the ball and goal until a shot is
> taken (a higher order result), at which point the strategy rule should
> recompute a new strategy: catch the ball. (Hmmm, I should have had it
> consider tipping the ball over the goal or just clearing it.)
>
> The strategy instance computes a series of "tactics" -- steps to take to
> achieve the strategy. Each tactic had a rule to decide when it had been
> achieved, or when it should be abandoned.
>
> The cool thing is that I am in a game with twenty-one other players so I
> can be in the middle of dribbling the ball downfield when my next sight
> input arrives and the worldview cells rerun and suddenly the rule to
> decide whether or not it is time to tap the ball suddenly gets back NIL
> for position of ball -- it has gone out of sight -- and with luck I have
> allowed for that and my design either drops back to tactic "find ball"
> or as the designer I have had the foresight to code up the "abandon"
> rule on the dribble strategy to go to true if I can no longer even see
> the ball -- I mean, what's the point, right? (OK, OK, I know, this is
> just an example, a real footballer does not need to see the ball
> continuously, no quibbling plz <g>.)

Actually, it would not be a quibble. Thanks to Cells I am now in a
position to insert a true mental model above the perception layer
compued from the raw layer (really just two-three kinds of input). The
mental model would persist over time in ways plausible given the laws of
physics and even certain assumptions ("if no one else has kicked the
ball it should be here based on the last observed location, speed , and
direction").

Great fun, programming this way.

kt

> But in any case it is all
> declarative. I cannot think about /particular/ events because the rules
> I write must work for all circumstances as long as the instance I am
> serving is alive. I decide what happens in /any/ event, or better, for
> any state of the surrounding world, specifically the state that matters
> to this slot being calculated by this rule.
>
> Look, it is a new paradigm, OK? Old if you count VisiCalc, but then it
> may as well be from Mars because we programmers have been hand-animating
> our models for fifty years and cannot imagine an application built in
> the mindset of CFO playing with VisiCalc. It took me a solid year to let
> go of the hand-animation habit even after falling in love with Cells,
> just to let you know how deep is the habit.
>
> kzo
>

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

Slobodan Blazeski wrote:
>>> 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?

CL-USER> (require :cells)
CL-USER> (defpackage :flow (:use :cells :utils-kt :cl))
CL-USER> (in-package :flow)
FLOW> (defmd node ()
in
out)
FLOW> (defmd double-node (node)
ut (c? (* 2 (^in))))
FLOW> (defmd print-node (node)
ut (c? (print (^in))))
FLOW> (defun path (&rest nodes)
(when (car nodes)
(multiple-value-bind (start node)
(apply #'path (butlast nodes))
(let ((self (make-instance (car (last nodes))
:in (if node
(c? (out node))
(c-in 0)))))
(values (or start self) self)))))
FLOW> (path 'double-node 'print-node 'double-node 'print-node)
DOUBLE-NODE26
FLOW> (setf (in *) 4)
8
16

What else do we have? Inverse and mod?
FLOW> (defmd mod3-node (node)
ut (c? (mod (^in) 3)))
FLOW> (defmd inverse-node (node)
ut (c? (if (eql (^in) 0) 0 (/ (^in)))))
FLOW> (path 'double-node 'inverse-node 'mod3-node 'print-node)
FLOW> (setf (in *) 4)
1/8
FLOW> (setf (in **) 1/8)
1

Satisfied?

Peter

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

Ken Tilton wrote:
>
>
> Slobodan Blazeski wrote:
>
>> 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.
>
>
> Let's turn that around, that question still has the tool in front: what
> applications (or libraries -- AC is having fun with a Web programming
> library built on Cells) do you consider cool?

btw, any simulation of course would be a blast. I think we are always
building models when we program computers, but when you are /really/
modelling something else (like a football match) Cells /really/ pays off.

That said, there is a second class of problem well-handled by Cells but
not so much cool as useful: driving another system from Lisp, whether it
be a C GUI, a sophisticated graphics engine like OpenGL, a Web browser,
or a C physics engine such as ODE. Over here the Lisp model Does Its
Thing, while Cell observers drive the other system over there, feedback
from that system coming in the form of C callbacks or http requests as
the case may be.

I always marvelled at the dual role played by Cells in something like
Cells-Gtk or Celtk -- animating the application model I have in mind
/and/ gluing that model to Gtk or Tcl/Tk, then I finally got it: Cells
is simply about change and simply gives application state causal power
over other application state. Causation and change are as fundamental as
it gets so dual/multiple roles are to be expected.

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

Ken Tilton wrote:
> Events are hard for Cells, change is easy/

Huh?

I would have thought (without close examination :-) that Cells was based
on "events".

Obviously, our nomenclature does not match.

From my perspective, a "change" is an "event". A change causes a chain of
reactions - a chain of events sent to the dependents interested in the
event.

I think of an "event" as a pulse of data (scalar or non-scalar). The pulse
is propagated throughout the system. It might cause other components to
produce further "events" (data pulses).

The pulses of data are uni-directional (no call-return protocol implied).

A reactive system.

I perceive "events" (uni-directional data pulses) to be the most basic unit
of communication between software components.

Reading your past few postings, I surmise that you have some other
interpretation of the concept of "event".

Would you please explain to me what you think of as an "event" vs. "change"?

Thanx

pt

Paul Tarvydas wrote:

> Here are two short papers about it:
>
> http://www.visualframeworksinc.com/DEBS2007-paper63.pdf
> http://www.visualframeworksinc.com/CCECE06-0379.pdf

This looks interesting. But looks like is is a bit different from Cells and
FBP. Is it right that in your system only one process (called "part" in
your system) is active at the same time? How would you implement the
telegram problem with your system?
http://en.wikipedia.org/wiki/Flow-ba...ram_Problem.22

In a multithreading FBP system, the ReadSeq process can run all the time,
feeding lines of strings to the next process, which runs in parallel. But
if I understand your system correctly, it would need to fill up the queue
to the next process with all lines of the whole file, then goes to idle and
then the next process reads and evaluates the queue.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Paul Tarvydas wrote:
> Ken Tilton wrote:
>
>>Events are hard for Cells, change is easy/
>
>
> Huh?
>
> I would have thought (without close examination :-) that Cells was based
> on "events".
>
> Obviously, our nomenclature does not match.

The nomenclature is fine, rather our subjects do not match.

I am talking about the programming experience. If I write a rule that
says the area is the length times the width then I am not thinking about
events. I /am/ taking huge delight in knowing that when in the course of
(yes) human events something transpires to occasion a change in the
width that the area will miraculously change at effectively (to other
code playing by the Cells rules) the exact same time. I believe this is
how Mr. Sulzberger resolved all these action at a distance matters, but
we not should digress in the absence of beer.

So the rule A = l x w is code written in an eventless mindset with its
inavriance enforced by one dataflow hack or another. Dandy.

But now we have a different rule that worries about a mouse-down event.
A button with a slot called "clicked?". But a mousedown /happens/, it
does not exist. Well, it exists ephemerally -- its existence is also its
demise. An example will make this clearer.

If I say:

(when (mouse-down *system*)
(when (pt-within (mouse-pos *system*) (bounding-box self))
...I have been clicked! Do amazing things...))

And suppose we get a mouse-down event in this GUI button which happens
to launch all ICBMs on Canada. That is OK, the button was disabled, the
launch commander was just showing off for the cute new recruit, got a
giggle out of her... I digress.

Now things get serious. No, not that. Canada freezes maple syrup
production to drive up prices. Bush hopes a third war will distract the
world from the first two he started and throws Congress a biscuit who
runs in a circle, rolls over, and declares the hockey puck a weapon of
mass destruction. All the silos go to defcon 42 and the launch interface
software enables all the gui buttons which now need to be redrawn with a
thicker frame so now they are bigger. The bounding box has changed. The
above rule runs.

The launch commander is necking with the recruit having left the mouse
positioned over the button, so if the mouse-down slot is populated...
bye bye moose people. That's OK, he is necking, not holding down the
mouse button. But what is the value of the mouse-down slot of the system
instance? Is it the same as when he clicked the disabled button to show
off? Bye bye moose people. And that would be an event.

So this is the tricky bit -- I can no longer think the way a spreadsheet
modeller thinks. They build models as if there was no such thing as
change by writing a rule that will be true regardless of events, for all
values of all independent variables: area is length times width. boom, I
am done. change is someone elses's problem -- ah, there ya go. In the
only paradigm most yobbos understand, they are in charge of propagating
change. They are not like me, they are all smart, they /like/ being in
charge. That is why they live in a forum where they can kick people who
joke about their typos. I digress. I am not smart like them, I love
automatic change management even more than I like automatic memory
management. I could programm faster in C with Cells/C than a yobbo could
program in Lisp without it. Hell, the not-to-be method would handle the
fricken GC...hmmm, should I go back? Run 20% faster? See, this is the
thing: Cells is just about change (or change and cause and effect but I
keep thinking they must be the same because of something Buddha said) so
automatic memory -- what is that about? Anyone? Good, Tommy. Change.

>
> From my perspective, a "change" is an "event". A change causes a chain of
> reactions - a chain of events sent to the dependents interested in the
> event.
>
> I think of an "event" as a pulse of data (scalar or non-scalar). The pulse
> is propagated throughout the system. It might cause other components to
> produce further "events" (data pulses).
>
> The pulses of data are uni-directional (no call-return protocol implied).
>
> A reactive system.
>
> I perceive "events" (uni-directional data pulses) to be the most basic unit
> of communication between software components.

Then stop thinking about communication between components. When you see
area = length x width, do you see length and width components
communicating wuth an area component? If so, fine, but does that not
also feel a tad contrived? Smalltalkers say 2+3 is a message to 2
telling it to add 3 to itself. chya. And worse than contrived, doh!, now
you are the one thinking about architecting the dataflow from here to
there to there to here to -- what? -- achieve the application
functionality. Cue Brooks, that does not scale. I need a declarative
paradigm that lets me write one rule at a time in isolation and have my
application emerge from the sum of the rules.


Think about the mindset of a spreadsheet modeller, the CFO using the
software to model the finances of his employer. Great, the huge model
gets filled with literal data such as the current prime rate or current
tax tables in some cells and formulas in others. [This happens to be
exactly how cell-driven slots work in CLOS.] OK, now the CFO starts
experimenting with different values for exchange rate and cost of fuel.
Both are volatile so he experiments a lot. The people who wrote VisiCalc
sweated bullets over getting the numbers displayed to recalculate
properly in the face of these change events, but the CFO just wrote
rules in a state of mind oblivious to change relying the underlying
tool to handle all that.

>
> Reading your past few postings, I surmise that you have some other
> interpretation of the concept of "event".

No, I just do not want to /think/ about events or change /while
programming/. That is a slippery slope that ends up with Brooks being
right: manual management of change by the programmer is ineluctably hard
once a too-low threshold of application complexity is reached.

I want to be precisely exactly completely totally is anybody listening
like a spreadsheet modeller, writing one rule for all time that will
compute the right value for this cell and have Cells handle the rest.

When after ten years of C I made automatic memory management a "must
have" on my shopping list for a new language, I was not saying I had no
intention ever again to allocate and later no longer need blocks of
memory -- I just did not want to think about it any more.

>
> Would you please explain to me what you think of as an "event" vs. "change"?
>

The trick then -- and hey, maybe I missed an easier way! -- is that
unlike anything a spreadsheet modeller deals with it seems to me there
is some data such as "the mouse just went to a down state" that forces
me to step away from a steady state state of mind and think about events
/at the application level/ -- not just something happening in the
background that Cells has to deal with. Ah, even better than the above
scenario: suppose the launch commander is doing a drag and drop and
happens to pass over the launch button just as it gets enabled. By GUI
standards that is /not/ a mouse click, tho the mouse would be down over
the enabled button.

As for there being an easier way, perhaps there is a way to duck the
special handing of events by using time as state (with Lisp time
granularity then being sufficiently imprecise as to take out Canada on
an unlucky day) but Tilton's Laws of Programming frowns on making things
more complicated in order to make things simpler: if a mousedown is not
like a mouse position they should be different in the same way.

peace, out, kzo

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

Ken Tilton wrote:
> If I say:
>
> (when (mouse-down *system*)
> (when (pt-within (mouse-pos *system*) (bounding-box self))
> ...I have been clicked! Do amazing things...))

The more I think about it, I believe this is how we should do events in
Cells-Gtk4. Well, deadline is on Friday. Some time after that.

> And suppose we get a mouse-down event in this GUI button which happens
> to launch all ICBMs on Canada. That is OK, the button was disabled, the
> launch commander was just showing off for the cute new recruit, got a
> giggle out of her... I digress.
>
> Now things get serious. No, not that. Canada freezes maple syrup
> production to drive up prices. Bush hopes a third war will distract the
> world from the first two he started and throws Congress a biscuit who
> runs in a circle, rolls over, and declares the hockey puck a weapon of
> mass destruction. All the silos go to defcon 42 and the launch interface
> software enables all the gui buttons which now need to be redrawn with a
> thicker frame so now they are bigger. The bounding box has changed. The
> above rule runs.
>
> The launch commander is necking with the recruit having left the mouse
> positioned over the button, so if the mouse-down slot is populated...
> bye bye moose people. That's OK, he is necking, not holding down the
> mouse button. But what is the value of the mouse-down slot of the system
> instance? Is it the same as when he clicked the disabled button to show
> off? Bye bye moose people. And that would be an event.

Thanks for that story. You made my day :-)

>
> The trick then -- and hey, maybe I missed an easier way! -- is that
> unlike anything a spreadsheet modeller deals with it seems to me there
> is some data such as "the mouse just went to a down state" that forces
> me to step away from a steady state state of mind and think about events
> /at the application level/ -- not just something happening in the
> background that Cells has to deal with. Ah, even better than the above
> scenario: suppose the launch commander is doing a drag and drop and
> happens to pass over the launch button just as it gets enabled. By GUI
> standards that is /not/ a mouse click, tho the mouse would be down over
> the enabled button.

I created my own little event handling for the cairo-drawing-area widget
in cells-gtk, which deals with clicks, selection (single elements and
multiple elements by drawing a transparent box), and dragging. And I
can tell you, the code is ugly.

If only I had thought of ephemeral cells. Well, time to think about
cells-gtk4.

Btw, my current project contains a physics simulator using cells-ode as
a backend, the gl-drawing-area widget of cells-gtk3 for visualization,
and a small DSL to specify scenes in terms of s-expressions. I will
factor out the relevant stuff and merge it will cells-gtk next week.