💡 simplistic I/O-based digital computing systems architecture

[brody4hire]

Digital computing systems can be implemented on CPUs, GPUs, FPGAs, etc. with help from languages such as Verilog, VHDL, C, C++, Java, JavaScript, LISP, Python, Rust, etc. etc.

Complexity is growing exponentially.

It is generally not trivial to move software from one language to another.

It can also be non-trivial to move between general-purpose CPU, GPU, FPGA, etc.

Many of these languages dictate the type of run-time environment.

Switching form synchronous to asynchronous programming can be non-trivial as well.

I discovered flow-based programming (FBP) back in 2011: https://en.wikipedia.org/wiki/Flow-based_programming

FBP seems to be capable of implementing large-scale computing systems from a combination of simplistic building blocks.

Unfortunately I have some areas of not total understanding of using FBP:

I do not understand how to cleanly use FBP for interactive UI or interactive I/O. There seems to be a chapter discussing this very topic but I had some real troubles following it.

Many web systems work directly based on request/response exchanges, while FBP is based on one-way data flow.

But I think FBP can help think of building digital computing systems out of simplistic block components connected by I/O interfaces.

The I/O interfaces and connections could be defined in a clean, simplistic specification language such as YAML.

The simplistic block components could be like mini VMs that can hold state and hierarchically manager other, lower-level mini VMs.

The mini VMs could be Java VMs, Web Assembly virtual machines, simplistic event-loops, etc.

Interactions between the block components could be asynchronous by default, with possibility to specify synchronous functional processing that could be considered working "inline" with another component.

In theory it should be straight-forward to transition specified digital computing implementations between browser-based VMs, lower-level servers, and potentially GPUs and FPGAs.

Ideally UIs can be made by UX designers or end-users rather than expert programmers that work on top of high-level I/O interfaces.

[brody4hire]

I thought of a couple more things to add.

State could be kept in a graph database in-memory or in storage. This may be interesting: https://redis.io/docs/stack/graph/design/

Composable task pipelines could be used to specify sequencing and behavior of processing work, may be done in serial or in parallel, a more flexible way of what we generally do in software procedures & functions.

[brody4hire]

Goal is that it should be possible to specify interfaces & behavior in a simplistic language such as YAML, XML, or S expression trees.

[brody4hire]

Interfaces should ideally be data-driven, in a similar fashion to FBP.

[brody4hire]

Tasks would be similar to the idea of protothreads from https://en.wikipedia.org/wiki/Contiki