Everything is a Fractal
In my mind, every problem can be subdivided.
I call such problems fractals.
Every sub-division of a problem can be further sub-divided.
Composite and Leaf Nodes
I see a solution-to-a-problem as a tree, branching downards.
A composite is a fractal.
A composite represents something that is sub-divided.
A leaf represents something that doesn't need to be sub-divided further.
Most current PLs do not encourage fractal-thinking. There is a problem and a lump of code. There is no tree of sub-divisions.
It is possible to write code in just about any PL by sub-dividing it, but, most PLs do not encourage this style.
Likewise, note that it is possible to write FP code in assembler, but assembler does not encourage the FP style.
Most PLs attempt to achieve fractal-thinking by using libraries of code, but this hasn't worked out so well. Libraries are rife with dependencies (see below).
Layers are Fractal Thinking
Fractal thinking leads to layered design.
Programming Code Should Be a Fractal
Compilers know how to inline function calls.
Nothing more than function calls and collections are needed at any composite level.
Low-level operations, like, "+", "cons", arrays, etc., are only needed at the leaf level.
Documentation Should Be a Fractal
Documentation should be arranged in a layered — need to know — manner.
Today, we have UNIX man pages + source code, or, 200-page documents like the gnu-make manual. These provide the top layers and bottom layers of documentation, but, nothing in between.
YAGNI Means Fractal
YAGNI means "you aren't going to need it".
YAGNI implies deferring work (operations).
YAGNI all the way down.
YAGNI at every layer.
Humans are bad at YAGNI layering. They need languages / notations that encourage layering.
Dependencies are Anti-Fractal
Layers that depend on one-another are invisibly "at the same level".
They are not layers.
Fractal-thinking requires lack of dependencies, isolation and superposition.
Scalability can be achieved only through the lack of dependencies.
- UNIX Man Pages - top level layer 1-2 pages, but no fractals beneath (refer to source code)
- Tabbed Views - across but no in
- Cascading Menus — fractal wannabes, with lousy UX
- Hierarchical File Systems — assembler for fractals
- Tree Widgets — fractals screaming to get out ; text-based solution to a problem which is not fundamentally text-based
- Code Libraries — failed fractals
- Theorem Provers — tends towards anti-fractal — all rules tend to be described at a single level without layering (it could be argued that each rule is a layer unto itself, but the result is a big lump of rules with no appreciable funnelling/choke points -- See Peter Lee for example of nesting)
- Peter Lee "Realistic Compiler Generator" — shows fractal design applied to Denotational Semantics — sub-divides domains into multiple layers
- Functions and Inlining — optimizations that should lead to more layering
- Macros — attempt to manipulate syntax skins in a language (see PEG) — too "flat" — macros constitute another bag of operations added to the "flat" operations provided by the language(s) ; macros could alleviate efficiency concerns for layered designs
- PEG — a way to make skins (SCLs) for facts
- Elm — flat message structure
- PLs — too many operators all at one level, only one syntax per language
- Scripts — bash supports isolation (&) and layering but only at a low level
- Backtraces — core dumps under a new name ; a way to escape having to provide good error messages
- Data Structures — premature optimization ; implementation details
- Relational Programming — PROLOG, miniKanren, etc. — a step in the right direction, but only a step
- O(n) Analysis — avoids the real issue (human UX is most important, emphasis on computer run-time is less important (or, is a component of UX analysis, necessary but not sufficient))
- GNU-anything — kitchen-sink approach, not layered
- open-source — not fractal, maintenance of code is a chore
- ORG-charts — business attempt at fractal-thinking
- OO — attempt at layering — unfortunately uses global stack for so-called "message passing"
- Structured Programming — attempt at layering ; attacks GOTOs but not design in general (GOTOs are not a problem, but unstructured use of GOTOs is the problem ; CPS is GOTOs-on-steroids (very useful for denotational semantics)).
- Global Variables — tamed by layering (scoped local variables instead of globals - again, the problem is not variables, but the unstructured use of variables)
- Packages — attempt at layering, attacking symptoms but not the underlying problem (the problem is how to layer DI, not how to cope with dependencies)
- Visual Programming — One doesn't need to think about pixels, except at the lowest level
- PDF — too low level ; only 2 layers - (1) text and (2) Forth (aka PostScript)
- DAWs — multiple tracks are only 1-level deep ; addition of buses supplies a 2nd level — but that's not enough
- S/SL — demonstration of layering to build non-toy code (e.g. how to build a Pascal compiler in '80s)
- HTML — low-level operations for layering ; HTML (XML) is but an assembler for layering
- Integers — not fractal
- Real Numbers — fractal ; floats (doubles) are just an approximation
- Measuring Tape and Rulers — fractal — every mark on a ruler can be further sub-divided
If your code uses "+", "cons", arrays, etc., it is at the bottom level (a leaf node). It is flat and non-structured.
need to know (n2k) https://guitarvydas.github.io/2021/03/16/Need-To-Know.html
 Feel free to substitute your favourite paradigm here, instead of FP. OO, Structured Programming, etc.
 Data structures should be built only at runtime. Computing power is "cheap".
 Data structures should only appear at the leaf level, everything else should only refer to data.
 DI means Design Intent