Call Return Spaghetti
2024-08-18
In the essay referenced below, I examine why a diagram of a Call/Return system makes less sense than a diagram of a concurrent system.
Call/Return operates in a LIFO - last-in first-out, stack-like - manner.
Adopting an alternate perspective - FIFO, first-in first-out, queue-like manner - allows us to represent diagrams more easily.
CPU chips implement CALL and RETURN instructions as single opcodes, but, they do not implement queue behaviour as single opcodes.
Most popular languages are generally function-based, e.g. C, Haskell, Python, Javascript, Smalltalk, etc. Such function-based languages tend to adopt a LIFO (callstack) perspective and tend to use CALL and RETURN opcodes to fake out the function-based paradigm.
Such languages allow programmers to implement FIFO queues, but, such languages encourage the use of LIFO stacks. This seemingly small difference subtly affects designs with function-based - stack-based - thinking. This difference ultimately encourages single-threaded design while making multi-threaded design more difficult to imagine and to implement, as witnessed by the fact that most languages relegate multi-threading to hefty code libraries, while treating functions as basic building blocks.
This subtle encouragement towards function-based thinking has led to the general impression that Visual Programming Languages (VPLs), node-and-wire Diagrammatic Programming Languages (DPLs), Actors, etc., are ineffective programming tools.
I argue that VPLs, DPLs, Actors, etc. are effective programming tools, but that their use is ultimately discouraged by the over-use of the function-based paradigm.
Further
https://guitarvydas.github.io/2020/12/09/CALL-RETURN-Spaghetti.html
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
What I am hearing is that dataflow notebooks, like ObservableHQ in my case, are a bit of an unholy matrimony between the two styles. FWIW I've been using their 'Runtime' dispatcher as a set of training wheels, given my heavy functional-programming bias. But my experience has been that important quality-of-life tools (map-reduce pipelines) that rely on the call stack are inherently hard to debug under the event-driven paradigm. And this seems to be the kernel of that idea.