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 ^[1] 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 ^[2] 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 ^[3] — 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.

https://guitarvydas.github.io/2021/01/24/superposition-2.html

https://guitarvydas.github.io/2021/01/22/superposition.html

https://guitarvydas.github.io/2021/01/16/Superposition.html

https://guitarvydas.github.io/2020/12/09/Isolation.html

Scalability

Scalability can be achieved only through the lack of dependencies.

Examples

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 ^[4] ; implementation details ^[5]
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,^[6] 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 2^nd 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

Bottom Level

If your code uses "+", "cons", arrays, etc., it is at the bottom level (a leaf node). It is flat and non-structured.