# 0D Is Important
I continue to struggle with finding ways to say "0D is important".
0D means "zero dependency".
# Problem of Perception
People don't "see" that there is a difference between functions and 0D
# Analogy - Perspective in Art
The perception problem is akin to pre- and post-perspective Art.
People didn't "see the need" for perspective in 2D artwork until "steam engine time"
[Paul Morrison used the phrase "Steam Engine Time"].
# Faster Horses
The perception problem is akin to:
> If I had asked people what they wanted, they would have said faster horses”
attributed to Henry Ford
# First Use-Case For Electric Motors
The perception problem is is akin to the first use-case for electric motors.
First use-case: pump water uphill to create artificial streams that could turn paddlewheels that ran factories [Digital Darwinism](https://www.amazon.ca/Digital-Darwinism-Survival-Business-Disruption/dp/0749482281)
We have developed epicycles due to dependencies and workarounds that manage dependences
Like *make*, *package managers*, *nixos*, etc.
Instead of simply removing all dependencies.
# Programming Should be Easy
Programming should be easy
But, modern programming using state-of-the-art languages is not easy.
- Prevalent notion that "multitasking is difficult".
- Prevalent notion that "distributed programming is difficult".
- Prevalent notion that "systems programming is difficult"
- and, can only be expressed using low-level languages
# If It's Difficult, Invent a New Notation
If something looks difficult, invent a new notation to describe it.
Create another layer to abstract-away the constructs in the current layer.
# Functional Programming
Functional programming is a notation for designing calculators.
Multitasking, IoT, internet, music and video sequencers, robotics programs, etc. are not calculators.
The dimension of time (*t*) cannot be ignored in a notation for building sequencers.
*Modeling* a fundamental concept (like *t*) is not as good as building a notation around the concept.
# Example: Evolution of Software Notations
- Electronics looked difficult, so opcodes and instruction sets were invented
- instruction sets are, but, a notation that abstracts-away the underlying rats' nests of complicated details of electrons flowing within oxides
- Opcodes and instructions sets using binary codes looked difficult, so Assembler was invented
- Assembler looked difficult, so C was invented
- C looked difficult, so higher-level languages were invented.
- Now, programming in higher-level languages looks difficult ...
# The Difference Between *Electronics* Design and *Software* Design...
Electronics components are 0D, completely isolated from one another
Software components are rife with dependencies and built-in synchronization, N0D (non-0D)
# Analogy: LEGO®
Single type - round peg
- just one type, not many types
A single type begets simplicity
- simplicity is "the lack of nuance"
0D - no interdependencies
- cutting one LEGO® block in half does not affect any other LEGO® block
- LEGO® blocks can be snapped together to form larger systems
- Larger systems built out of LEGO® blocks can be broken down by removing blocks
- Blocks from one system can be reused to build other systems
- Complete sub-systems can be broken away from existing systems and can be used to build other systems
# Software Libraries and Functions
Libraries of functions cannot be easily reused due to inter-dependencies.
Libraries of functions cannot be easily tested in a stand-alone manner, due to inter-dependencies.
# OOP Does Not Implement "Message Passing"
Message passing in OOP languages is implemented using N0D Call/Return
Rhetorical question: Is OOP an abstract notation, or, is OOP a technique for programming CPUs?
- methods imply the use of blocking functions (see "functional notation")
# Functional Notation
Functional notation is based on blocking state machines
- e.g. `f(x)` blocks the caller until the callee returns a value
- this is a state machine, the state is recorded as bookmarks on The Call Stack
"Blocking" thwarts the efforts of Operating Systems to control applications, and, makes Operating Systems more dificult to implement, needing more nuance and workarounds, often resulting in latent gotchas.
# Sector Lisp
[Sector Lisp](https://justine.lol/sectorlisp/) is an example of how small and beautiful FP notation can be if it is left alone and not overloaded with concepts that are outside of its "sweet spot".
Jart's GC is only 40 bytes [sic, not K, not M, not G, but, bytes].
Sector Lisp: https://justine.lol/sectorlisp/
# Functional Notation and Hardwiring Names
`f(x)` hardwires the name `f` into the callers code
Making it difficult to use the code in other situations.
# OOP "Encapsulation" Is Not Enough
"Encapsulation" encapsulates data
"Encapsulation" does not encapsulate control flow
# Control Flow And Data Flow
Control flow and data are not the same concepts
A single notation for both cannot be used without compromising one or the other.
"Data" is layout of information *in storage*
"Control flow" is layout of behaviour *in time*
Previous attempts to subsume both, data and control flow, into the same notation have resulted in schizophrenic programming languages that sacrifice one or the other notion.
Popular fad today: sacrifice control flow layout, while emphasizing data layout.
# Structured Programming
Attempt to apply structuring concepts to control flow layout
Recommendation for structuring -> single input, single output
- abstraction of control flow layout
# Analogy: Human Interaction, "Free Will"
Humans understand how to deal with independent units (e.g. other humans).
Hard-wiring synchronization into an underlying notation defies human intuition, giving rise to the notion that "programming is difficult" and requiring many years of schooling to learn to think in terms of over-synchronized units
Humans understand blocks on diagrams to represent independent units
Mapping diagrams to Synchronous Programming Languages[^spl] defeats the purpose of creating diagrams
SPLs do not faithfully represent 0D diagrams.
# Solutions: No Name Calling
[[2022-07-11-No Name Calling]]
# Solutions: Extending Flow-Based Programming
[[2022-07-11-Extending Flow-Based Programming]]