Frank Buss wrote:
> Sohail Somani wrote:
>
>> Frank Buss wrote:
>>
>>> What is a Cells synapse? I didn't used Cells very much, but I don't think
>>> this maps very well, because in FBP all processes are running in parallel,
>>> which is not possible with Cells.
>> Why is it not possible?
>
> We have to ask this Kenny, but I don't think that Cells is multithreading
> safe and the concept of Cells is not to have many parallel running
> processes.

Gotcha but the general concept can be executed in parallel if done properly.

Or maybe I should say "done a specific way".

Ken Tilton wrote:
>> Rainer Joswig wrote:
>>
> That sounds different, as if one is writing code that says, OK, now send
> a message to precisely here. That is classic imperative management of
> state change and its consequences by the programmer, and has nothing of
> the declarative quality of Cells.

Btw, I am not disagreeing that Actors sounds like dataflow, but as Mr.
Buss says it depends on the meaning of the word "dataflow" and as I said
the devil is in the details, tho in this case this is no detail: the
beauty of a spreadsheet is that I never worry about who I have to tell
when I change, the software tends to that automatically, nor do I have
to step back from writing my formula to do explicit stuff (as in a
subscribe/notify pattern) in order to get updated -- I just write my rule.

Same with Cells.

>
> I would suggest the metaphor of a spreadsheet, but that has actually
> been resoundingly and repeatedly demonstrated as insufficient to make
> the point. :)

Oops. :)

kt

Ken Tilton wrote:

>> Rainer Joswig wrote:
>>
>>>
>> I would suggest the metaphor of a spreadsheet, but that has actually
>> been resoundingly and repeatedly demonstrated as insufficient to make
>> the point. :)
>
> Oops. :)

Actually, in the latest version of Excel, if your addins are specified
as reentrant (Excel4 API-using addins are not, iirc), MS Excel may
calculate cells in parallel.

Atleast thats what I last heard when dealing with Excel 12 propaganda.

Ken Tilton wrote:
>> Ken Tilton wrote:
>>
> Btw, I am not disagreeing that Actors sounds like dataflow, but as Mr.
> Buss says it depends on the meaning of the word "dataflow" and as I said
> the devil is in the details, tho in this case this is no detail: the
> beauty of a spreadsheet is that I never worry about who I have to tell
> when I change, the software tends to that automatically, nor do I have
> to step back from writing my formula to do explicit stuff (as in a
> subscribe/notify pattern) in order to get updated -- I just write my rule.
>
> Same with Cells.
>

But we cellsers won't give up on it:

http://pypi.python.org/pypi/Cellulose/0.2

Cells begat PyCells, PyCells begat Trellis and Cellulose. So there are
three Python implementations of Cells now, tho I have a feeling PyCells
is moribund. Cellulose gets a lot of downloads, I think because it is
used in something else. Not sure how Trellis is doing.

kt

On Sat, 24 May 2008 21:48:50 +0200, Frank Buss <fb>
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.
>
>I think this is wrong, because the information packets are the data, which
>are traveling through the connections.

Not exactly ... the "control IPs" are not application data but
commands to start/stop processes and make/break connections. Thus
control IPs at least are logically part of the wiring of the
distributed application. I suppose it's debatable.

Right now I class FBP as interesting rather than really useful. My
first impression upon reading the book is that the author[*] hasn't
adequately addressed program scaling complexity. From what I can see,
FDP programs will be at least as complex as MP programs.
[*] I'm unsure of the author's surname. Being a stupid American, the
name "van Nostrand Reinhold", as written, looks strange. Google
didn't help. My Anglish guess would be "Reinhold van Nostrand" but I
wouldn't dare to state it as if I really knew.



The elements of FBP are similar to Carriero and Gelernter's Linda
system (the author admits this). The major difference is that FBP
seems to be designed as a rather traditional distributed component
scheme that requires explicit process creation and IPC connections
between components. The components of a Linda application communicate
via a (logical) shared scoreboard maintained cooperatively by Linda
servers. Linda processes and connections are created implicitly by
naming them as data sources or sinks, and lightweight processes can
migrate between servers (Java-Linda makes this particularly effective
because servers can exchange bytecode even in heterogenous networks).

Existing Linda implementations don't scale physically as well as MP
does and FBP might, but Linda's programming model is completely
ignorant of the number of CPUs. Server implementation permitting, the
same Linda program code will run unchanged on any number of processors
and transparently exploit any component parallelism in the
application.

George

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

>George Neuner wrote:
>>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

On May 26, 9:30 pm, George Neuner <gneuner2/> wrote:
[..]
> 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:
[..]
> (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

On May 24, 3:17 pm, "Alex Mizrahi" <udode>
wrote:
[..]
> 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> wrote:
[..]
>>
> 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?
[..]

Slobodan Blazeski wrote:
> On May 24, 3:17 pm, "Alex Mizrahi" <udode>
> wrote:
>>
> 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

On May 27, 4:54 pm, Ken Tilton <kennytil> wrote:
[..]
>
> 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:[..]
> ECLM talk:[..] Hide quoted text -
>
> - Show quoted text -
Ok you got me. Any idea for cool problem with cells? Pure cells only
no gui crap please.