2024-07-07-Can Software Be Chunked And Layered?
One of my interests is “concurrency”. In addition, I used to design and build my own electronic hardware.
From these interests, I conclude that we can chunk and layer software so that it is more readable and understandable to other programmers.
My conclusion is that function-based programming should be used only to describe the innards of (hardware) actors. “Something else” should be used to express the interactions of (hardware) actors with other (hardware) actors. That “something else” is: true, asynchronous message passing.
Can we build message passing systems that are structured and don’t require all of the bloat of using operating systems?
Yes.
Processes are just closure wannabes. We can use closures instead of processes. We need heavy-handed processes, and, MMUs, and, protection rings only when developing software and trying to protect against having run-away, buggy programs clobber other programs. After development, of course, the software is debugged and doesn’t need that kind of protection. This is true in hardware development. Zero defects in the field. No need for “continuous delivery”. Challenge: why isn’t software as reliable as this?
Messages are simple objects that contain two things:
Port identifier. A tag. A name.
Data. A blob of bits. Not sculpted in any way, except that the content of blobs is understood by the sender and the receiver.
To build a truly asynchronous message passing system, software asynchronous blocks (SWABs) cannot determine where messages are sent to, nor where messages come from. A dispatcher must be implemented. Note that all operating systems do, in fact, implement dispatchers.
A simple dispatcher is ... simple.
Loop, if any SWAB has messages on its input queue, dispatch the SWAB for exactly one message. Pop the first message off the the SWAB’s queue, then dispatch the SWAB with that message. The SWAB can only place output messages on it’s own output queue, it cannot route the messages itself - the dispatcher1 does that.
Structured Message Passing can be based on tried and true principles, such as Org Charts and layering. Layers elide detail, but, do not delete detail. Layers push detail down to other layers and don’t inflict all information on a reader at once. Layers send requests down and receive summaries up.
Recursive operation. There are two kinds of SWABs:
Containers
Leaves.
Containers compose SWABs into little networks. Containers can contain Containers or Leaves. Containers dispatch their children SWABs and then mop up their outputs by routing messages internally (or, to their own output ports).
Leaf SWABs contain executable code. I guess that you could use FP to write that code, but, I tend to prefer to use something like state machines and statecharts.
SWABs react to each incoming message, in order.
SWABs can react to only one message at a time.
A Leaf SWAB inhales one message and does something with it, maybe producing zero or more output messages. One complete processing step in one go.
Once it has processed the message, a Leaf SWAB returns control back to the dispatcher.
A Container SWAB, on the other hand, reacts to input messages by punting them down to their children. A Container is busy if any of its children are busy or ready to be busy (i.e. have messages on their input queues).
A Container cannot inhale another message if it is busy. A dispatcher repeatedly wakes up SWABs. If a Container SWAB is busy, then it just pokes its children, otherwise it inhales another input message (if any).
Note that children can react to messages in a step-like manner. Sometimes it takes more than one message to complete a full reaction. A child steps through the reaction, a little bit at a time, when poked.
See Also
statecharts: https://guitarvydas.github.io/2023/11/27/Statecharts-Papers-We-Love-Video.html
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
Container