Conflation of Parameter Delivery and Scheduling
What does the following line of code do?
fn(a)
It:
- Delivers the parameter “a” to the function fn, and, it
- Schedules the function fn.
What does the following line of code do?
fn(a,b)
It:
- Delivers two parameters to fn - both, at the same time, and, it
- Schedules the function fn.
Scheduling
Normally, we use an operating system to determine scheduling, but, in the case of a function CALL, we override the operating system.
If the operating system really, really, really wants to override the override, it resorts to preemption and yanks the CPU out from under the CALLer.
Simultaneous Parameter Delivery
Is it true that we always want to deliver parameters all-at-once?
That works when building calculators, but doesn’t work so well when building internet software.
Most of the popular GPLs (general purpose language) make it easy to build calculators, but don’t make it easy to build internet software.
Yes, it is possible to build internet software using calculator languages, but it could be easier.
ASCs - Asynchronous Software Components
It is possible to build languages tuned for building asynchronous applications.
I think we need to think about:
- Asynchronous operation.
- Components that run forever.
- Sending Messages.
- Structuring designs using hierarchy.
- Relativity.
Relativity
Components can only reference (call, query, etc.) components that are “nearby”. UNIX gives us a notation for this “./hello”, “../world”, etc.
Scalability
Any component that is tangled up with another component is dependent on the other component and is, therefore, not scalable on its own.
Humanity has solved this problem before. The most obvious example is the hierarchical organization of businesses. Humanity has even invented a phrase for non-scalability, e.g. “Going Over the Boss’s Head”
Asynchronous Operation
Humanity has invented notations for asynchronous operations and teaches this notation to 5-year old kids.
Humanity calls this notation sheet music.
The notation is hard-real-time.