5 ms·

Have you looked at reactive streams? There are some interesting semantics for splitting and combining data and only describing the different flows independently

Have you looked at reactive streams? There are some interesting semantics for splitting and combining data and only describing the different flows independently that handle the data as it flows through. http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-graphs.html http://doc.akka.io/docs/akka-stream-and-http-experimental/1.... There are split semantics where the tuples are simply fed into other flows. And then merge semantics where flows recombine into a single flow for further processing.

amelius 11y ago
What if the program is constantly altering the plumbing beneath the streams? Isn't this kind of programming not becoming a bit "messy" then?
- nightski 11y ago
  Instead of creating a mutable set of plumbing, you can create an equal design that has static plumbing with altering flows based on data. Maintaining the latter is going to be a lot easier than the former anyways.
- ninjakeyboard 11y ago
  I don't know - maybe I don't see the argument clearly. If you want to keep state, then look at the actor model. If you want to talk about functional programming, then we can assume things are immutable. If you want to deal with multiple streams of data, I think combinators do just fine. If you want to choose which function to pass into higher order functions at runtime, then indeed you can define functions and just reference them. If you want to split data up, you can use all of the nice function composition and pattern matching available in languages like scala and haskell. To split a string, take half to upper and half to lower, you can use tuples, or zip and unzip, partition etc. Stuff like that. None of it seems messy but I'm probably not understanding this article correctly.
samuell 11y ago
Yes, I have been checking reactive streams, but they seem to take a similar approach as most other functional languages supporting chained lazy-evaluated functions. Even though they have specialized functions and constructs for branching out and merging, I'd argue that being limited to chaining functions, IMO it quickly grows unmaneagable when dealing with any more complex data flow networks. AFAIS, you'll get super-long chains of function calls, that are really hard to change, or inspect. Compare that with the syntax proposed in the post, or some other FBP syntax like the one in GoFlow [1], where you define each connection between an outport and an inport on one line. IMO this gets exponentially more manageable, readable and maintainable. [1] https://github.com/trustmaster/goflow#basic-example https://github.com/trustmaster/goflow#basic-example

amelius 11y ago

What if the program is constantly altering the plumbing beneath the streams? Isn't this kind of programming not becoming a bit "messy" then?

nightski 11y ago
Instead of creating a mutable set of plumbing, you can create an equal design that has static plumbing with altering flows based on data. Maintaining the latter is going to be a lot easier than the former anyways.
ninjakeyboard 11y ago
I don't know - maybe I don't see the argument clearly. If you want to keep state, then look at the actor model. If you want to talk about functional programming, then we can assume things are immutable. If you want to deal with multiple streams of data, I think combinators do just fine. If you want to choose which function to pass into higher order functions at runtime, then indeed you can define functions and just reference them. If you want to split data up, you can use all of the nice function composition and pattern matching available in languages like scala and haskell. To split a string, take half to upper and half to lower, you can use tuples, or zip and unzip, partition etc. Stuff like that. None of it seems messy but I'm probably not understanding this article correctly.

samuell 11y ago

Yes, I have been checking reactive streams, but they seem to take a similar approach as most other functional languages supporting chained lazy-evaluated functions. Even though they have specialized functions and constructs for branching out and merging, I'd argue that being limited to chaining functions, IMO it quickly grows unmaneagable when dealing with any more complex data flow networks. AFAIS, you'll get super-long chains of function calls, that are really hard to change, or inspect. Compare that with the syntax proposed in the post, or some other FBP syntax like the one in GoFlow [1], where you define each connection between an outport and an inport on one line. IMO this gets exponentially more manageable, readable and maintainable. [1] https://github.com/trustmaster/goflow#basic-example https://github.com/trustmaster/goflow#basic-example