3 ms·

I agree with you about the visual-layout-makes-programming-easy spiel, but it does seem like there might be a little more to flow-based programming than that. A

by gruseom 13y ago

I agree with you about the visual-layout-makes-programming-easy spiel, but it does seem like there might be a little more to flow-based programming than that. At least a few smart people seem to take it seriously (e.g. on LtU), and dataflow as a computational paradigm has a lot of research behind it and hasn't seen a whole lot of implementation. It's not out of the question that someone could apply it in a new way that would make some classes of application easier to build. I'm open to that and would find it interesting. But after having looked repeatedly for an intelligible technical explanation of FBP, I'm starting to think that the idea is either a trivial repackaging of a well-known model (like Unix pipes, or CSP with directed graphs) or is better shelved with the snake oil. The fact that it's typically accompanied by rather sensational language is not a point in its favour. Edit: it's too bad that the programming model is getting lumped in here with the visual programming schtick. Those are two different things. (Of course the former would get no PR without the latter.)

jerf 13y ago
To be clear, I fine with their attempt to make any product they intend to make. I'm very skeptical about it due to the fact that it's been tried a lot, but hey, their money, their choice, maybe they'll make it stick, maybe they'll make a niche market work (LabVIEW, etc), who knows. It's the rhetoric I'm objecting to. Which bodes poorly, IMHO; if they really believe this gibberish then it's more likely they'll make some very bad business decisions, such as resisting finding a good niche in favor of trying to take over too much stuff. There's a lot of prior art to learn from here, and if they've learned as little of it as that marketing spiel implies, their odds of success are very, very low.
scott_s 13y ago
I consider this an instance of stream programming.
- gruseom 13y ago
  Do you think of stream programming as a kind of dataflow programming? If not, what's the difference? I suppose "dataflow" is an overloaded term, and the fact that its various meanings have quite a bit in common doesn't help.
  - scott_s 13y ago
    Definitely, yes. In section 2 of this paper, I tried to explain how our language is related to what are typically called "synchronous dataflow" languages, or just SDF languages: http://www.scott-a-s.com/files/pact2012.pdf http://www.scott-a-s.com/files/pact2012.pdf Slide 11 of this talk makes the same point, but with less words: http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf
  - seanmcdirmid 13y ago
    Data flow when used as a converse of control flow is quite well defined. Are you thinking in terms of how data flows across the system or in terms of control? Stream programming usually uses data flow at the top level and control flow in the atomic components connected together (we can have compound components that involve more data flow). Once you add control lines to your system, however, you are basically re-encoding explicit control flow as data flow.
    - gruseom 13y ago
      I might have been unclear; what I meant was that the different programming languages or models that people call "dataflow programming" (spreadsheets, Lucid, Oz, FBP, etc.) have a lot of differences between them; and on top of those there is dataflow analysis in compilers, dataflow hardware architectures, and so on.
      - seanmcdirmid 13y ago
        Data-flow is a broad term that doesn't mean one specific thing, but it is usually used correctly in what it means; e.g. data-flow analysis contrasts nicely with control-flow analysis. I don't find it confusing. I believe FBP primarily deals with data flow, not control flow, but the "flow" in FBP seems to be left intentionally ambiguous.

by gruseom 13y ago

jerf 13y ago

To be clear, I fine with their attempt to make any product they intend to make. I'm very skeptical about it due to the fact that it's been tried a lot, but hey, their money, their choice, maybe they'll make it stick, maybe they'll make a niche market work (LabVIEW, etc), who knows. It's the rhetoric I'm objecting to. Which bodes poorly, IMHO; if they really believe this gibberish then it's more likely they'll make some very bad business decisions, such as resisting finding a good niche in favor of trying to take over too much stuff. There's a lot of prior art to learn from here, and if they've learned as little of it as that marketing spiel implies, their odds of success are very, very low.

scott_s 13y ago

I consider this an instance of stream programming.

gruseom 13y ago
Do you think of stream programming as a kind of dataflow programming? If not, what's the difference? I suppose "dataflow" is an overloaded term, and the fact that its various meanings have quite a bit in common doesn't help.
- scott_s 13y ago
  Definitely, yes. In section 2 of this paper, I tried to explain how our language is related to what are typically called "synchronous dataflow" languages, or just SDF languages: http://www.scott-a-s.com/files/pact2012.pdf http://www.scott-a-s.com/files/pact2012.pdf Slide 11 of this talk makes the same point, but with less words: http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf
- seanmcdirmid 13y ago
  Data flow when used as a converse of control flow is quite well defined. Are you thinking in terms of how data flows across the system or in terms of control? Stream programming usually uses data flow at the top level and control flow in the atomic components connected together (we can have compound components that involve more data flow). Once you add control lines to your system, however, you are basically re-encoding explicit control flow as data flow.
  - gruseom 13y ago
    I might have been unclear; what I meant was that the different programming languages or models that people call "dataflow programming" (spreadsheets, Lucid, Oz, FBP, etc.) have a lot of differences between them; and on top of those there is dataflow analysis in compilers, dataflow hardware architectures, and so on.
    - seanmcdirmid 13y ago
      Data-flow is a broad term that doesn't mean one specific thing, but it is usually used correctly in what it means; e.g. data-flow analysis contrasts nicely with control-flow analysis. I don't find it confusing. I believe FBP primarily deals with data flow, not control flow, but the "flow" in FBP seems to be left intentionally ambiguous.