Asynchrony - Little Networks
Function-based, synchronous thinking cannot - by definition - deal with true asynchronous operation.
At best, function-based, synchronous thinking can reduce some asynchronous problems to step-wise simultaneity. In the synchronous paradigm, asynchronous nodes are considered to be clockwork-like synchronous nodes, allowing certain kinds of synchronous calculations to be performed. This avenue of thinking cannot address the majority of cases where nodes cannot be synchronized at a low level.
This kind of synchronous, function-based thinking is like clockwork and cannot deal with “free will” (true asynchrony). We need to invent the “clutch” - something that lets us slip gears and de-synchronize them, at least temporarily.
We have many examples of difficulties imposed by forcing the idea of synchronous functions onto true asynchrony, such as the horror of callbacks, and, the increasing complexity of things like .then, futures, promises, etc.
Obviously, we can construct truly asynchronous systems, like the internet, using only synchronous, function-based notations, but, we can only do so by expressing nodes as being internally synchronous and using assembler-level operations (like thread libraries) to define reactions of nodes to incoming asynchronous events.
We should be able to create programming languages that express asynchrony at a higher level, but, we can’t do that using synchronous, function-based thinking.
Networking Protocols
The idea of defining network protocols between truly asynchronous nodes seems to be on the right track.
What are reasonable languages for defining protocols?
State machines and Statecharts, etc.
Should We Stop Using Function-Based Languages in Lieu of State-based Languages?
Should we dump the use of function-based languages and adopt, whole-hog, languages based on state machines?
No.
We need to make many languages - many paradigms - co-exist. We need a program development workflow that uses multiple paradigms.
Little Networks
So, if defining networks using protocols is a hopeful approach, why don’t we use these ideas more often?
Networking has become associated with heavy-weight computer hardware usage and heavy-weight operating system processes, etc. Thus, networking is generally ignored at the programming language, smaller-grain levels.
We have the ability to build little networks today.
Nodes can be programmed as closures.
Communication between nodes must be done in a non-synchronous manner. For this, we can simply use queues. Queues are not inherent to function-based languages, which use FIFO callstacks, yet, LIFO queues can be easily built in those languages.
We would benefit from having a syntax that made LIFO queues as easily accessible as FIFO callstacks.
Allowing multiple queues per component tends to lead to pain (in the form of deadlock). So, we should allow only one input queue per component. This doesn’t get rid of deadlock issues, but, allows software architects to deal with such issues explicitly, instead of relying on someone else’s ideas of how to construct general solutions to specific problems.
A single queue-per-component model, also, ensures that order of incoming messages is preserved. This allows race conditions to be handled using state-based thinking. Time-based order of operations is not well-handled in synchronous, function-based languages. In fact, most so-called “race conditions” in synchronous, function-based languages are forms of accidental complexity, not actual, physics-based races. Physics tells us that there is but one race condition - the possibility that two events arrive simultaneously - so quickly that our hardware cannot discern which one happened first.
We, also, need a way to “structure” asynchronous communication. We need the equivalent of “structured programming” for message passing. My essays and blogs on Structured Message Passing, and Routing, are aimed at the use of layers to make it possible to cleanly structure asynchronous, message-passing systems.
See Also
References: https://guitarvydas.github.io/2024/01/06/References.html
Blog: https://guitarvydas.github.io/
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/Jjx62ypR
Leanpub: https://leanpub.com/u/paul-tarvydas
Gumroad:
https://tarvydas.gumroad.com
Twitter: @paul_tarvydas