Elephant in the Room
Computers are asynchronous.
Async vs. Sync
Trying to program computers using synchronous methods is a tactic.
Over-using the synchronous tactic will cause accidental complexity, for example callback-hell, etc.
Step 1 Before Step 2
Most people (non-programmers) already understand asynchronous processes.
For example, cooking recipes are often arranged in an asynchronous manner:
- Boil the potatoes.
- While the potatoes are boiling, chop up …”
Five (5) year-old children are taught hard realtime notations
- piano lessons
- music scores.
CEOs understand asynchrony inherently and use whiteboards to communicate their intentions.
CEOs don’t want to be bothered by the enigneering details. This does not mean that they are ignoring the details, just deferring them (to Architects and Engineers). Our notations can deal with all of the details while presenting less detail at each step - using layers. Provenance can be accomplished in layers.
Asynchrony is about control-flow.
OO does not express Control-flow conveniently.
FP does not express Control-flow conveniently.
Rendezvous multi-tasking does not express Control-flow conveniently (rendezvous is merely another tactic for reducing async problems into sync problems by essentially ignoring the async portion).
CPS (Continuation Passing Style) does not express Control-flow conveniently. CPS is, basically, GOTO in disguise. Yes, GOTO can express control-flow, but it isn’t convenient. Yes, CPS can express control-flow, but it isn’t convenient.
This leads into the notion of decoupling syntaxes - one syntax for data structuring, another syntax for control-flow structuring. Two Syntaxes For Every Language II and so on.
Different syntaxes for:
- Implementation, vs.,
One Language To Rule Them All
One Language to Rule Them All is a bad idea.
This approach closes the mind.
The idea of GPL (General Purpose Language) falls into this category. Use SCNs2 instead of GPLs.
How to Express Async?
ASCs - Asynchronous Software Components
(see my Blog, search for “Isolation”, Software Components”, “Software Components 101”, “ASC”, “DaS”, etc., etc.)
Diagrams of asynchronous components can form control-flow-based paradigms.
Diagrams built using the synchronous paradigm tend to fail. Such diagrams are harder to build and are often less meaningful. This (synchrony) has led to the (untrue) notion that node-and-arrow diagrams don’t work.