# The Fundamental Problem
All programming languages and all operating systems have one (1) thing in common:
- over-use of synchronization.
Programmers have built towers of epicycles to work around this fundamental issue.
Once understood, it is easy to overcome this commonality.
# Discussion
For example, programmers need to employ elaborate schemes to decouple applications built with implicitly-synchronous languages - like Haskell, C++, Python, etc.
One such elaborate scheme is the invention of *operating systems*. Operating systems employ the brute-force technique of *preemption* to yank control away from overly-synchronous applications.
Applications, that use the very common technique of function-calling, actually employ *ad-hoc* blocking.
> [!information] Functions perform ad-hoc blocking
> Functions - even in FP (functional programming) languages - are State Machines that mutate a global variable. At their most basic, functions contain 2 states: (1) pre-call, and, (2) post-return. When a function calls another function, the caller *blocks* waiting for the callee to return a value. Since function calls can be inserted into code at any point, they represent ad-hoc *blocks* that take away control-of-blocking from the Operating System.
> [!information] Functions mutate a global variable
> The call-stack is a shared piece of memory, a "global variable" supported by hardware (using the CALL and RETURN instructions). All routines in a single CPU share the same call-stack. The call-stack is used for bookmarking return-points ("continuations"). The call-stack is essentially a dynamically scoped list of bookmarks (space-optimized to be an array).
> Early CPUs did not have a call-stack. The call-stack was added later.
> [!information] Functions inhibit routing
> In the function-call paradigm, data / message routing is reduced to a single choice - the data is *always* routed back to the caller. Any other kind of routing strategy is reduced to second-class status and given the derisive name *side-effect*.
What systems should not be strongly coupled?
What systems should be strongly coupled?
- operating system processes -> concurrency -> decoupling
- preemption
- thread safety
- libraries vs. testing
- loops
- internet, IoT, Robotics, NPCs, Blockchain
- concurrency
- decouple
- libraries of functionality
- bookmark mutates callstack
- function call overrides blocking control and takes it away from O/S
- text-based programming languages
- due to 1950's hardware limitations and premature optimization
- thread safety
- due to mutation
- remove mutation -> Sector Lisp -> anti-bloatware
# Syntax for Decoupling
... ideas ...
Send (port, data) *- function call syntax*
snd[port, data] *- special syntax*
port << data *- special syntax, less-less-than*
port = data *- assignment-like syntax, requires checking of LHS to see if it's a variable or a port*
port ⇠ data *- unicode operator*
data ⇢ port *- unicode operator*
all of the above transpiled into a function call to Send (...)
when simulating decoupling in sync paradigm