Re:The paradigms of programming
by mpweiher on Tuesday January 30, 2018 @04:38AM
(#16264033)
There are a number of architectural styles that aren't call/return:
1. Dataflow
With the popular variant pipes + filters. There is also synchronous dataflow, which can be compiled to state machines. This has recently been bastardized as "FRP" (distinct from Conal Eliot's original FRP).
What's kind of amusing is that traditional programs typically get translated to dataflow variants twice: first, the compiler turns procedures into a dataflow graph and generates code from that, later most OOO speculative processors turn the computation into more or less a dataflow graph again.
2. Asynchronous messaging
See Erlang/Actor model. You send messages (calls), but they don't return.
3. Implicit invocation/broadcast
You send out messages/broadcasts. Clients can register. There is no 1:1 correspondence between call-sites and receivers. May also be asynchronous (but doesn't have to be).
4. Constraints
Both dataflow constraints (see spreadsheets) and "solver" constraints. You just specify the relations you want to hold.
5. Coroutines
Normal call/return runs the callee to completion. Coroutines interleave. The Floyd paper mentions nested coroutines, which I have to look at.
etc.
A good reference is Software Architecture: Pespectives on an Emerging Discipline by Shaw and Garland
1. Dataflow
With the popular variant pipes + filters. There is also synchronous dataflow, which can be compiled to state machines. This has recently been bastardized as "FRP" (distinct from Conal Eliot's original FRP).
What's kind of amusing is that traditional programs typically get translated to dataflow variants twice: first, the compiler turns procedures into a dataflow graph and generates code from that, later most OOO speculative processors turn the computation into more or less a dataflow graph again.
2. Asynchronous messaging
See Erlang/Actor model. You send messages (calls), but they don't return.
3. Implicit invocation/broadcast
You send out messages/broadcasts. Clients can register. There is no 1:1 correspondence between call-sites and receivers. May also be asynchronous (but doesn't have to be).
4. Constraints
Both dataflow constraints (see spreadsheets) and "solver" constraints. You just specify the relations you want to hold.
5. Coroutines
Normal call/return runs the callee to completion. Coroutines interleave. The Floyd paper mentions nested coroutines, which I have to look at.
etc.
A good reference is Software Architecture: Pespectives on an Emerging Discipline by Shaw and Garland