We certainly want to make bigger and bigger systems. Would using multiple paradigms in addition to FP, like coroutines, hierarchical state machines, statecharts, reactive parts, other kinds of little engines, spreadsheets, DSLs like BNF, stack-based state machine engines for parsing text, regular expression engines, etc. allow system size to grow with less overhead and improved isolation and scoping than using only a single function-based / functional-programming model?
Making larger systems by simply adding more functions to an infinite plane of code drives us towards bloatware. We end up needing to add more code and we end up needing to add baubles to simple, off-the-shelf CPU architectures. We have added baubles like MMUs, protection rings, caching, etc. in order to grow system size using only the functional paradigm.
FP encourages only one set of ways for doing control flow - top to bottom sequencing, CALL, RETURN, throwing exceptions. This limits the set of choices for control flow. On top of this, FP tangles data flow with control flow. For example, to pass data to a callee, the caller must, also, block (blocking is a control-flow issue). Other possibilities like multi-way transitions, side-effects, etc. are severely discouraged in the functional programming model.
FP encourages only a limited range of dataflow options. In FP, all input data must arrive at the same time and all output data must be sent at the same time. This complicates reasoning about sequenced events. To put order on events, one typically resorts to using timestamps and must resort to the introduction of extra code to compare timestamps, instead of using the much easier concept of something like "event A arrived before event B" and "event X was sent before event Y". FIFO queues naturally present data in that kind of order, whereas stacks present data in reverse order. Stacks are LIFO queues, not FIFO queues. The concept of stacks permeates functional programming engines. I suspect that programmers find it difficult to deal with concurrency and asynchrony because of the over-use of stacks at low levels.
Potential Hints
The technology for stackless, massive parallelism is understood, in the form of electronics schematics. The problem with schematics is that schematics are not well-scoped and contain tangled, spaghetti-like connections that are hard to comprehend. Harel’s Statecharts offer an interesting first step in taming this kind of problem through hierarchicalization of system states.
UNIX processes and pipelines offer a compelling perspective on complete control-flow isolation and encapsulation, as well as asynchrony. Completely isolated software components, akin to UNIX processes, can be seamlessly interconnected in a manner reminiscent of LEGO® bricks. However, function-based code discourages such flexibility due to the inherent blocking nature of the function calling protocol. It is noteworthy that UNIX processes are inherently equipped with multiple inputs and outputs (FDs). The text-based syntax of /bin/*sh commands primarily discourages the utilization of such multiple ports. Notably, UNIX-like processes can be considered the equivalent of closures and anonymous functions in contemporary programming languages, with the exception that functions inherently possess only a single input and output and do not fundamentally express LIFO-like event sequencing.
My contention is that programmers want to create larger systems by snapping software-LEGO® blocks together. Code libraries look like a good idea, but, actually contain internal dependencies which prevent LEGO®-izing code. The key is to decouple data flow from control flow.
I’ve tied several of these ideas together in PBP - Parts Based Programming (aka 0D). A simple example of PBP is shown in the arith example. The repository for development tools is, also, on github. Diagram-less PBP is, also, possible, but, I find that I quickly grow tired of using only textual syntax for expressing asynchronous concepts.
See Also
Email: ptcomputingsimplicity@gmail.com
References: https://guitarvydas.github.io/2024/01/06/References.html
Blog: guitarvydas.github.io
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: “programming simplicity” https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Substack: paultarvydas.substack.com