I like that the code example seems to indicate they took the concept of "ports" from flow-based programming, which might be one of it's absolute strongest points:
That is, enabling data flow connections between individual inputs/outputs, and not just between components, which otherwise is too limiting, and typically causes a lot of extra syntax to handle that routing otherwise.
That aside: really cool article! Dataflow just pops up everywhere as a really, really useful abstraction, and our languages don't support it well as a general mechanism.
Instead we tend to have specialized dataflow-y tooling for one area of programming where the advantages are so significant that the impedance mismatch is worth it nonetheless.
I think you are right, and I should have done a search on that before. Found now that FBP inventor cites someone Weinberg from 1975 about them (though FBP is supposed to be from around 69-70, so might be a somewhat parallel discovery):
> Now what are "IN" and "OUT" that our pseudocode receives IPs from and sends them to? They are not the names of connections, as this would tie a component's code to one place in the network, but are things called "ports". "Portae" means "gates" in Latin, and ports (like seaports) can be thought of as specific places in a wall or boundary where things or people go in or out. Weinberg (1975) describes a port as
"... a special place on the boundary through which input and output flow... Only within the location of the port can the dangerous processes of input and output take place, and by so localizing these processes, special mechanisms may be brought to bear on the special problems of input and output."
Still, I'm amazed at how it took so long before they became mainstream in data flow oriented libraries and DSLs.
And it seems J.P. Morrison was also highlighting Named ports as particularly useful, which is also perhaps what I should have highlighted in my initial comment above.
It's gotten better lately it seems, but a lot of tools skipped that part, which now requires tons of specialized syntax just for routing of multiple parallel streams.
I think the main example on the landing page is a bit counterintuitive?
Rock Paper Scissors but the graph presents the reveal as a reaction to the observation? In a loop? And somewhere there's a min-delay of a magical 1 sec? Why 1 sec and not 0.1 sec? Can this build up and the players get out of sync? (A bit strange to 'just wait, lol' if the language aims at solving problems in distributed systems).
Overall the example would be better if it separated the game from the players and also split out the repeat loop.
Maybe let both player reveal to a host and then receive a result (and the choices) ~ This way both players can be sure that the choice of the other player is independent of the observation.
(I know that the example is 'correct' in that the choice is made independent of the observation but I think the example could be improved if it solved some of the coordination problems involved in the scenario more cleanly through code architecture).
Overall I quite like the idea of having this polyglot meta language!
I don't really understand what problem this is meant to solve at first glance. It'd be nice to see a simple example program involving concurrency written in plain Python, then a discussion of the annoying bookkeeping involved in avoiding concurrency errors and what traps would be easy to fall into, and then an example of how the same thing would be implemented using Lingua Franca and an explanation of how eliminates the bookkeeping and traps.
I like that the code example seems to indicate they took the concept of "ports" from flow-based programming, which might be one of it's absolute strongest points:
That is, enabling data flow connections between individual inputs/outputs, and not just between components, which otherwise is too limiting, and typically causes a lot of extra syntax to handle that routing otherwise.Wrote about it in the context of workflow systems way back (https://livingsystems.cc/posts/workflows-dataflow-not-task-d...)
---
Edit 11:12 CET: I realize that “named ports” better captures what I had in mind here, as elaborated in a comment below.
Ports are a general feature of components in the software architecture literature (and corresponding systems).
In addition, connectors also become structured.
Objective-Smalltalk uses polymorphic connectors to adaptively and mostly automatically choose the level of granularity you want to operate at.
https://dl.acm.org/doi/10.1145/3689492.3690052
---
That aside: really cool article! Dataflow just pops up everywhere as a really, really useful abstraction, and our languages don't support it well as a general mechanism.
Instead we tend to have specialized dataflow-y tooling for one area of programming where the advantages are so significant that the impedance mismatch is worth it nonetheless.
I think you are right, and I should have done a search on that before. Found now that FBP inventor cites someone Weinberg from 1975 about them (though FBP is supposed to be from around 69-70, so might be a somewhat parallel discovery):
> Now what are "IN" and "OUT" that our pseudocode receives IPs from and sends them to? They are not the names of connections, as this would tie a component's code to one place in the network, but are things called "ports". "Portae" means "gates" in Latin, and ports (like seaports) can be thought of as specific places in a wall or boundary where things or people go in or out. Weinberg (1975) describes a port as
"... a special place on the boundary through which input and output flow... Only within the location of the port can the dangerous processes of input and output take place, and by so localizing these processes, special mechanisms may be brought to bear on the special problems of input and output."
https://www.jpaulmorrison.com/fbp/concepts_book.shtml
Still, I'm amazed at how it took so long before they became mainstream in data flow oriented libraries and DSLs.
And it seems J.P. Morrison was also highlighting Named ports as particularly useful, which is also perhaps what I should have highlighted in my initial comment above.
It's gotten better lately it seems, but a lot of tools skipped that part, which now requires tons of specialized syntax just for routing of multiple parallel streams.
---
Thank you for kind words!
I think the main example on the landing page is a bit counterintuitive?
Rock Paper Scissors but the graph presents the reveal as a reaction to the observation? In a loop? And somewhere there's a min-delay of a magical 1 sec? Why 1 sec and not 0.1 sec? Can this build up and the players get out of sync? (A bit strange to 'just wait, lol' if the language aims at solving problems in distributed systems).
Overall the example would be better if it separated the game from the players and also split out the repeat loop.
Maybe let both player reveal to a host and then receive a result (and the choices) ~ This way both players can be sure that the choice of the other player is independent of the observation.
(I know that the example is 'correct' in that the choice is made independent of the observation but I think the example could be improved if it solved some of the coordination problems involved in the scenario more cleanly through code architecture).
Overall I quite like the idea of having this polyglot meta language!
I don't really understand what problem this is meant to solve at first glance. It'd be nice to see a simple example program involving concurrency written in plain Python, then a discussion of the annoying bookkeeping involved in avoiding concurrency errors and what traps would be easy to fall into, and then an example of how the same thing would be implemented using Lingua Franca and an explanation of how eliminates the bookkeeping and traps.
Here are Python examples, that you can test in the playground: https://github.com/lf-lang/playground-lingua-franca/tree/mai...