4 ms·

Yes, it can. The simplest way is with when/unless vertices which take a boolean input and some other inputs, and which either output the other inputs if the bo

Yes, it can. The simplest way is with when/unless vertices which take a boolean input and some other inputs, and which either output the other inputs if the boolean input is true/false, or output nothing.

galaxyLogic 6y ago
But can the boolean input come from some other component to which I send data?
- DonaldFisk 6y ago
  Yes, it would typically be the output of a boolean function. It wouldn't be much use if it couldn't.
  - galaxyLogic 6y ago
    Yes boolean function, but wouldn't that have to be a synchronous function, one that the component doing the decision making calls? I understand that there can be loops in the dataflow and feedback can alter the processing logic of a component at some point in the future - since processing is async, the alteration can only happen in the future. But when a component needs to make a decision, not alter its processing logic but simply make a choice, can it somehow 'ask a question" from some other component which is part of the data-flow, before it it decide which branch of the data-flow to send data to? My question is simply is it possible and/or practical to do general programming with only (asynchronous) dataflow between the components/functions/units-of-computation? Or do we need both synchronous and asynchronous components/functions/agents etc. ?
    - DonaldFisk 6y ago
      Dataflow doesn't require synchronization because vertices wait until there are values with the same tag on all their inputs before executing. In pure tagged dataflow systems, asking a question doesn't happen: programs are directed graphs and like most other programming systems vertices have to wait for values. However, at a higher level, you could have vertices sending messages to one another and receiving answers back.
      - galaxyLogic 6y ago
        > vertices have to wait for values So computation can not start before I have all the inputs, right? But when I --a vertice-- am doing a computation, I would like to ask for more data from some other component, so that I can complete my calculation. So how could I get such data except as one of my input? But I must have all my inputs already, else I would not be executing. This would then seem to be at the core of the difficulty with data-flow programming. Once a computation of a node has been activated, it can not ask for help from anybody, because it must have all its inputs present before it starts doing its calculation. Does this make sense ???
jancsika 6y ago
This gets unwieldy quickly. Consider the ajax pattern: b = a .filter1() .filter2() .filter3() .filter4(); if (b.foo()) { return a.filter5(); } else { return a.filter6(); } For visual programming, AFAICT you have to feed `a` downstream twice: once to filter5 and once filter6 in preparation for the conditional branch. That requires one of the following: * intersecting lines, which are way more visually complicated to read than the code above (and can quickly create visual ambiguities which as a class do not exist in a text-based language) * one line which loops under the bottom of one of the downstream objects, which is visually distracting (especially if you have more than two branches) edit: clarification
- galaxyLogic 6y ago
  That gets to the core of my puzzlement. In terms of dataflow if 'b' is an 'agent' then b.foo() is a message we send to it and then we use the result of b.foo() for further decision making. But in a typical dataflow-diagram data flows in one direction only, there is no link in the diagram from "b" to "result of b.foo()". A diagram could not (easily?) describe the fact that we get the 'b' from one component and then we send the message "foo" to that component 'b". The data-path from this component to "b" could hardly show in the diagram because "b" is the response to a previous request which could be one of many possible alternative responses. I'm not sure if I can express or even think about this very clearly but questions like this make me doubt the generality of dataflow as an alternative to current-day programming practice.
  - DonaldFisk 6y ago
    Researchers at the University of Manchester and elsewhere built computers which implemented dataflow at the hardware level. The main reason we don't have them is because of Moore's Law: wait a few years and a single CPU will be just as fast as multiple dataflow CPUs. There are historical reasons why we're programming in text in mostly imperative languages: graphics terminals were either not very good or very expensive, and computers had single CPUs, until quite recently.
- DonaldFisk 6y ago

galaxyLogic 6y ago

But can the boolean input come from some other component to which I send data?

DonaldFisk 6y ago
Yes, it would typically be the output of a boolean function. It wouldn't be much use if it couldn't.
- galaxyLogic 6y ago
  Yes boolean function, but wouldn't that have to be a synchronous function, one that the component doing the decision making calls? I understand that there can be loops in the dataflow and feedback can alter the processing logic of a component at some point in the future - since processing is async, the alteration can only happen in the future. But when a component needs to make a decision, not alter its processing logic but simply make a choice, can it somehow 'ask a question" from some other component which is part of the data-flow, before it it decide which branch of the data-flow to send data to? My question is simply is it possible and/or practical to do general programming with only (asynchronous) dataflow between the components/functions/units-of-computation? Or do we need both synchronous and asynchronous components/functions/agents etc. ?
  - DonaldFisk 6y ago
    Dataflow doesn't require synchronization because vertices wait until there are values with the same tag on all their inputs before executing. In pure tagged dataflow systems, asking a question doesn't happen: programs are directed graphs and like most other programming systems vertices have to wait for values. However, at a higher level, you could have vertices sending messages to one another and receiving answers back.
    - galaxyLogic 6y ago
      > vertices have to wait for values So computation can not start before I have all the inputs, right? But when I --a vertice-- am doing a computation, I would like to ask for more data from some other component, so that I can complete my calculation. So how could I get such data except as one of my input? But I must have all my inputs already, else I would not be executing. This would then seem to be at the core of the difficulty with data-flow programming. Once a computation of a node has been activated, it can not ask for help from anybody, because it must have all its inputs present before it starts doing its calculation. Does this make sense ???

jancsika 6y ago

This gets unwieldy quickly. Consider the ajax pattern: b = a .filter1() .filter2() .filter3() .filter4(); if (b.foo()) { return a.filter5(); } else { return a.filter6(); } For visual programming, AFAICT you have to feed `a` downstream twice: once to filter5 and once filter6 in preparation for the conditional branch. That requires one of the following: * intersecting lines, which are way more visually complicated to read than the code above (and can quickly create visual ambiguities which as a class do not exist in a text-based language) * one line which loops under the bottom of one of the downstream objects, which is visually distracting (especially if you have more than two branches) edit: clarification

galaxyLogic 6y ago
That gets to the core of my puzzlement. In terms of dataflow if 'b' is an 'agent' then b.foo() is a message we send to it and then we use the result of b.foo() for further decision making. But in a typical dataflow-diagram data flows in one direction only, there is no link in the diagram from "b" to "result of b.foo()". A diagram could not (easily?) describe the fact that we get the 'b' from one component and then we send the message "foo" to that component 'b". The data-path from this component to "b" could hardly show in the diagram because "b" is the response to a previous request which could be one of many possible alternative responses. I'm not sure if I can express or even think about this very clearly but questions like this make me doubt the generality of dataflow as an alternative to current-day programming practice.
- DonaldFisk 6y ago
  Researchers at the University of Manchester and elsewhere built computers which implemented dataflow at the hardware level. The main reason we don't have them is because of Moore's Law: wait a few years and a single CPU will be just as fast as multiple dataflow CPUs. There are historical reasons why we're programming in text in mostly imperative languages: graphics terminals were either not very good or very expensive, and computers had single CPUs, until quite recently.
DonaldFisk 6y ago