2 ms·

> It means you work with constraints, for example dataflow constraints. I'm not sure anyone else would call that anything but an interface (not an "implements

> It means you work with constraints, for example dataflow constraints. I'm not sure anyone else would call that anything but an interface (not an "implements programmatic interface"). I was being gracious with separation of concerns, because a SoC implies a dataflow constraint that isn't necessarily enforced only by mechanism, where there can also be convention. > What's VNA? von Neumann Architecture > The fact that you need to create these centralised updater methods is non-obvious, and leads to a bunch of related non-local changes. Also a muddle. Synchronization requires synchronous operations. There are refresh rates physically and render methods virtually. This is obvious and not adhering to that is unmaintainable, due to confounding variables. If there were {N} programs to manage {N} components under a singular view, how is messaging handled? Messaging requires synchronization, which requires something akin to a render(). You have physical limitations on how many states can be maintained at any given moment and mapping limitations ie 2^3 (DNA) > 2 (Turing) states giving you more complexity, which is still bounded. An underlying dataflow constraint is still fundamentally a system that has to transfer the same information.

mpweiher 5y ago
>> It means you work with constraints, for example dataflow constraints. > I'm not sure anyone else would call that anything but an interface I am sure that nobody calls that an "interface". First, a dataflow constraint is nothing like an interface (for one it is an implementation). It's also a standard term of art. https://www.cs.cmu.edu/~amulet/papers/toplas-constraint-experience.pdf https://www.cs.cmu.edu/~amulet/papers/toplas-constraint-expe... https://arxiv.org/abs/1104.2293 https://arxiv.org/abs/1104.2293 http://web.eecs.utk.edu/~bvanderz/quickplan.html http://web.eecs.utk.edu/~bvanderz/quickplan.html http://www.hosobe.org/wp-content/uploads/iccae2020.pdf http://www.hosobe.org/wp-content/uploads/iccae2020.pdf ... > This is obvious and not adhering to that is unmaintainable, due to confounding variables It's actually not obvious, as shown in the paper. And it is not intrinsically necessary. It is necessitated by the architectural mismatch. > Messaging requires synchronization, which requires something akin to a render(). Exactly. Messaging pretty much requires this, or more generally "call/return" requires this as a user-visible and user-defined construct, due to to the mismatched architectures. Dataflow constraints, as shown in the paper, do not require anything like this at all. A more appropriate architectural style makes the requirement vanish into nothingness. > An underlying dataflow constraint is still fundamentally a system that has to transfer the same information. Exactly, but it allows us to structure those transfers in a vastly more straightforward and obvious manner, as demonstrated in the paper.

mpweiher 5y ago

>> It means you work with constraints, for example dataflow constraints. > I'm not sure anyone else would call that anything but an interface I am sure that nobody calls that an "interface". First, a dataflow constraint is nothing like an interface (for one it is an implementation). It's also a standard term of art. https://www.cs.cmu.edu/~amulet/papers/toplas-constraint-experience.pdf https://www.cs.cmu.edu/~amulet/papers/toplas-constraint-expe... https://arxiv.org/abs/1104.2293 https://arxiv.org/abs/1104.2293 http://web.eecs.utk.edu/~bvanderz/quickplan.html http://web.eecs.utk.edu/~bvanderz/quickplan.html http://www.hosobe.org/wp-content/uploads/iccae2020.pdf http://www.hosobe.org/wp-content/uploads/iccae2020.pdf ... > This is obvious and not adhering to that is unmaintainable, due to confounding variables It's actually not obvious, as shown in the paper. And it is not intrinsically necessary. It is necessitated by the architectural mismatch. > Messaging requires synchronization, which requires something akin to a render(). Exactly. Messaging pretty much requires this, or more generally "call/return" requires this as a user-visible and user-defined construct, due to to the mismatched architectures. Dataflow constraints, as shown in the paper, do not require anything like this at all. A more appropriate architectural style makes the requirement vanish into nothingness. > An underlying dataflow constraint is still fundamentally a system that has to transfer the same information. Exactly, but it allows us to structure those transfers in a vastly more straightforward and obvious manner, as demonstrated in the paper.