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:
player2.reveal -> player1.observe
player1.reveal -> player2.observe
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.