I’ve been mulling on how to explain the Call Return Spaghetti article in a way that makes sense in a different way.
Number 1 is the fact that I see "functions" as artificial constructs built on top of subroutines -- AND -- "functions" involve data flow + control flow, i.e. not just data flow.
Number 2 is the fact that I see “software” as only being soft hardware.
When a "function" calls another "function", the caller blocks and waits for a response from the callee - that's a control flow decision. You need to use preemptive operating systems to regain control of the control flow. A handler for preemption used to be small - roughly a page of code in Holt’s book, (Chapter 10 - Implementing a Kernel), but, it is my impression that operating systems have become rather bloated over the years.
Snipping the cord between data flow and control flow makes it easier to "reason about" control flow problems (like distributed computing, robotics, internet, IoT, etc, etc.), AND, snipping the cord is really easy using our current programming languages (and, is the ultimate point of the Call Return Spaghetti article).
I find that simply adding FIFO queues to our tool-belts and treating units of software as reactive anonymous functions (reactive closures, internally synchronous, if you wish) allows me to create layers of asynchronous software instead of big blobs of brittle clockwork.
The technique of using synchronous, sequential programming languages is applicable to programming single CPUs and computers, much like we’ve been doing for the past half-decade. I think that the synchronous, sequential technique is unsuitable for asynchronous, non-sequential programs. We can program single reactive units of software this way, but trying to program systems containing massive parallelism using the synchronous, sequential paradigm is counter-productive, akin to using GOTO to manually program CPUs in the past.
Understanding CPUs From First Principles
I’ve begun putting together a playlist of short videos that address the understanding of CPU operation from first principles, in the hope that seeing what is underneath functions in programs might trigger new ideas on modernizing our programming workflows and languages.
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: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Substack: paultarvydas.substack.com