Add minimalism ideologies

AWESOME_MINIMALISM_IDEOLOGIES.md

@@ -0,0 +1,221 @@
+# Awesome Minimalism Ideologies in Code
+
+A curated reading list for the kind of software philosophy represented by
+[suckless.org](https://suckless.org/philosophy/): small programs, few
+abstractions, transparent behavior, restrained dependencies, and complexity
+that is visible rather than hidden. This is **not** a list of “write less code”
+slogans. Some entries disagree with suckless on portability, UX, or acceptable
+trade-offs; all are useful lenses for deciding what complexity is justified.
+
+## Core texts
+
+1. **[The Unix Philosophy](http://www.catb.org/~esr/writings/taoup/html/ch01s06.html) — Eric S. Raymond**
+   - **Idea:** Build small, sharp tools; make programs cooperate through text
+     streams; prefer transparency and simplicity to cleverness.
+   - **Why read it:** The closest broad articulation of the ecosystem that made
+     suckless possible. Treat it as a historical and practical catalogue, not
+     a rigid law.
+   - **Keywords:** composability, pipes, text interfaces, small tools.
+
+2. **[Worse Is Better](https://www.dreamsongs.com/WorseIsBetter.html) — Richard P. Gabriel (1989)**
+   - **Idea:** A design that is simple to implement and adequate at its
+     interface can spread more successfully than a more complete but complex
+     design.
+   - **Why read it:** The classic case for implementation simplicity and
+     incremental growth. It also explains a risk of minimalism: “worse” can
+     become entrenched before its weaknesses are repaired.
+   - **Keywords:** simplicity, adoption, incremental design, MIT vs. New Jersey.
+
+3. **[Rise of “Worse Is Better”](https://www.dreamsongs.com/RiseOfWorseIsBetter.html) — Richard P. Gabriel (1991)**
+   - **Idea:** A follow-up reflection on what happened when simple, portable
+     Unix-style systems won.
+   - **Why read it:** Read immediately after the original for the author’s own
+     qualifications and the social consequences of the thesis.
+   - **Keywords:** Unix, portability, evolution, trade-offs.
+
+4. **[A Plea for Lean Software](https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf) — Niklaus Wirth (1995)**
+   - **Idea:** Hardware growth encouraged wasteful software; progress should
+     favor economy, disciplined construction, and comprehensible systems.
+   - **Why read it:** A direct, forceful manifesto against bloat from one of
+     computing’s most influential language and systems designers.
+   - **Keywords:** bloat, efficiency, discipline, comprehensibility.
+
+5. **[The Rule of Least Power](https://www.w3.org/2001/tag/doc/leastPower.html) — W3C TAG (2006)**
+   - **Idea:** Choose the least powerful language or mechanism that adequately
+     solves the problem, because less expressive mechanisms are easier to
+     understand, analyze, reuse, and constrain.
+   - **Why read it:** A precise design rule for resisting unnecessary Turing
+     completeness, configuration languages, and frameworks.
+   - **Keywords:** least power, declarative design, analysis, constraints.
+
+6. **[Simple Made Easy](https://www.infoq.com/presentations/Simple-Made-Easy/) — Rich Hickey (2011 talk)**
+   - **Idea:** “Simple” means not intertwined; it is different from “easy.”
+     Complexity comes from complecting concerns, state, and time.
+   - **Why read it:** The strongest vocabulary for arguing that a convenient
+     abstraction is still a bad abstraction when it entangles independent
+     things.
+   - **Keywords:** simplicity, complexity, state, values, separation.
+
+7. **[Out of the Tar Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf) — Ben Moseley and Peter Marks (2006)**
+   - **Idea:** Accidental complexity is overwhelmingly caused by mutable state;
+     reduce it with functional core ideas, declarative data, and controlled
+     effects.
+   - **Why read it:** A more formal companion to “suck less”: it identifies a
+     specific source of software complexity rather than merely disliking size.
+   - **Keywords:** accidental complexity, state, functional programming,
+     declarative systems.
+
+8. **[A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/book.php) — John Ousterhout (book and free notes)**
+   - **Idea:** Complexity is the central enemy. Design deep modules with simple
+     interfaces, eliminate special cases, and invest in design rather than
+     merely adding layers.
+   - **Why read it:** An important corrective to naïve minimalism: fewer lines
+     or smaller modules are not automatically simpler; a *deep* module can
+     hide a large amount of coherent complexity.
+   - **Keywords:** complexity, deep modules, abstraction, special cases.
+
+## Short, sharp essays and engineering rules
+
+9. **[The Best Code Is No Code At All](https://blog.codinghorror.com/the-best-code-is-no-code-at-all/) — Jeff Atwood (2007)**
+   - **Idea:** Every line has ownership, failure, and maintenance cost; first
+     ask whether the feature or mechanism should exist.
+   - **Why read it:** The most useful minimalism test before implementing a
+     “small” helper, dependency, option, or service.
+   - **Keywords:** deletion, YAGNI, maintenance cost, restraint.
+
+10. **[The Law of Leaky Abstractions](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) — Joel Spolsky (2002)**
+    - **Idea:** Non-trivial abstractions leak details of the systems beneath
+      them; pretending otherwise produces surprises and weak operational
+      understanding.
+    - **Why read it:** Supports suckless’s preference for visible mechanisms
+      and inspectable source, while not claiming abstractions are useless.
+    - **Keywords:** transparency, abstraction, operations, failure modes.
+
+11. **[No Silver Bullet—Essence and Accident in Software Engineering](http://www.cs.unc.edu/~brooks/NoSilverBullet.html) — Frederick P. Brooks Jr. (1986)**
+    - **Idea:** Software has irreducible essential complexity; tools can remove
+      accidental complexity but cannot make difficult domain problems vanish.
+    - **Why read it:** A guardrail against cargo-cult minimalism. Remove
+      accidental machinery, but model essential domain complexity honestly.
+    - **Keywords:** essential complexity, accidental complexity, realism.
+
+12. **[The Power of 10: Rules for Developing Safety-Critical Code](https://spinroot.com/gerard/pdf/P10.pdf) — Gerard J. Holzmann (2006)**
+    - **Idea:** Deliberately restrict language features, function size,
+      recursion, dynamic allocation, and unchecked assumptions to make code
+      analyzable and dependable.
+    - **Why read it:** Minimalism as an enforceable reliability discipline,
+      rather than as aesthetic preference.
+    - **Keywords:** constraints, verification, safety, C, static analysis.
+
+13. **[How do we tell truths that might hurt?](https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html) — Edsger W. Dijkstra (1975)**
+    - **Idea:** A program’s intellectual manageability matters; programming
+      should reduce the gap between what humans can reason about and what
+      machines execute.
+    - **Why read it:** A compact philosophical foundation for choosing designs
+      that fit in a human mind.
+    - **Keywords:** intellectual manageability, rigor, programming practice.
+
+14. **[The Unix Programming Environment](https://archive.org/details/UNIXProgrammingEnvironment) — Brian W. Kernighan and Rob Pike (1984)**
+    - **Idea:** Make programs do one job well and join them with a stable,
+      simple interface: the shell and text stream.
+    - **Why read it:** The practical original for Unix-style composition; use
+      it alongside the Unix Philosophy rather than treating later summaries as
+      the source.
+    - **Keywords:** shell, filters, composition, interfaces.
+
+## Kevlin Henney: enterprise-software perspective
+
+15. **[1968](https://www.youtube.com/watch?v=wi66pDC47J4) — Kevlin Henney (SCLConf 2018)**
+    - **Idea:** Much of modern enterprise software repeats problems that were
+      already understood in the 1960s and 1970s. Revisit the era’s lessons on
+      modularity, structured programming, and managing complexity rather than
+      mistaking new tooling for progress.
+    - **Why read/watch it:** A thoughtful antidote to enterprise novelty and
+      architecture fashion. Henney’s point is not nostalgia or rejecting
+      scale; it is that software should remain understandable despite scale.
+    - **Keywords:** enterprise software, history, structured programming,
+      modularity, complexity.
+
+## Recent sources (2020–2026)
+
+This section is deliberately restricted to material published in the requested
+time window. The window does not have an equally canonical successor to the
+Unix texts; these are the strongest recent statements of the same values.
+
+15. **[Rediscovering the Small Web](https://neustadt.fr/essays/the-small-web/) — Parimal Satyal (2020)**
+    - **Idea:** The personal, hand-made, link-driven web is an alternative to
+      centralized, algorithmically mediated platforms.
+    - **Why read it:** A warm manifesto for software and publishing that stay
+      small enough to be understood and owned by their makers.
+    - **Keywords:** small web, personal publishing, independence, human scale.
+
+16. **[Locality of Behaviour](https://htmx.org/essays/locality-of-behaviour/) — Carson Gross (2020)**
+    - **Idea:** The behavior of a unit of code should be visible from that unit;
+      avoid scattering a feature’s structure, state, and behavior across a
+      project’s folders and layers.
+    - **Why read it:** A concrete frontend architecture principle that reaches
+      the same goal as suckless: make the mechanism obvious to the reader.
+    - **Keywords:** locality, hypermedia, frontend, inspectability.
+
+17. **[What is the Small Web?](https://ar.al/2020/08/07/what-is-the-small-web/) — Aral Balkan (2020)**
+    - **Idea:** The web should preserve personal publishing and human-scale
+      spaces rather than force everyone into surveillance platforms.
+    - **Why read it:** Connects technical smallness to agency, independence,
+      and decentralization.
+    - **Keywords:** small web, independence, decentralization, ownership.
+
+18. **[The Small Web Is Beautiful](https://benhoyt.com/writings/the-small-web-is-beautiful/) — Ben Hoyt (2021)**
+    - **Idea:** Favor fast, plain, durable, independently published web pages
+      over ad-tech-heavy and JavaScript-dependent sites.
+    - **Why read it:** Applies the same values to delivery: a minimal program
+      is not enough if its website, documentation, and distribution path are
+      bloated.
+    - **Keywords:** small web, performance, static sites, durability.
+
+19. **[The Grug Brained Developer](https://grugbrain.dev/) — “Grug” (2022)**
+    - **Idea:** Software complexity grows beyond any individual’s ability to
+      hold it in mind; choose boring, direct techniques and resist cleverness
+      that expands the cognitive surface area.
+    - **Why read it:** Comic in voice but serious in diagnosis. It is a useful
+      counterweight to architecture astronautics and dependency-driven design.
+    - **Keywords:** cognitive load, boring technology, directness, complexity.
+
+20. **[Slow Software](https://www.inkandswitch.com/slow-software/) — Ink & Switch (2023)**
+    - **Idea:** Optimize development for reflection, quality, and long-term
+      care rather than release velocity and feature throughput.
+    - **Why read it:** Broadens minimalism beyond code size: a system remains
+      humane when the organization leaves time to understand and simplify it.
+    - **Keywords:** software pace, craftsmanship, maintenance, sustainability.
+
+## Operational practice
+
+21. **[The Twelve-Factor App](https://12factor.net/) — Adam Wiggins (2011)**
+    - **Idea:** Keep deployable services portable and legible through explicit
+      configuration, stateless processes, backing-service boundaries, and
+      parity across environments.
+    - **Why read it:** Not a minimalism manifesto, but a disciplined recipe for
+      avoiding hidden environment-specific complexity in networked software.
+    - **Keywords:** explicit configuration, portability, processes, operations.
+
+## A compact synthesis
+
+Use these texts as a sequence of questions, not commandments:
+
+1. **Can it be deleted?** — Atwood.
+2. **Can it be expressed with a less powerful mechanism?** — W3C TAG.
+3. **Can independent concerns remain unentangled?** — Hickey.
+4. **Does the interface hide one coherent capability, rather than conceal
+   unrelated machinery?** — Ousterhout.
+5. **Can a maintainer inspect, test, and reason about failure without learning
+   a framework’s private universe?** — Spolsky, Dijkstra, Holzmann.
+6. **Does the remaining complexity belong to the domain, or did we introduce
+   it?** — Brooks, Moseley, Marks.
+7. **Will the software stay small in distribution and operation, not only in
+   its source tree?** — Wirth, Small Web, Twelve-Factor.
+
+## Important tension
+
+Suckless-style minimalism is most valuable when it removes **accidental**
+complexity. It becomes harmful when “small” is used to reject accessibility,
+security, internationalization, reliable error handling, documentation, or
+real domain requirements. A good minimal system has the *fewest concepts that
+still make the correct behavior clear and dependable*.