From 536cd437d0e9060a35f1912623bd3c969a37cd45 Mon Sep 17 00:00:00 2001 From: Marnix Krul Date: Tue, 27 Oct 2026 09:19:28 +0100 Subject: [PATCH] Add minimalism ideologies --- README.md => AWESOME_AI.md | 0 AWESOME_MINIMALISM_IDEOLOGIES.md | 221 +++++++++++++++++++++++++++++++ 2 files changed, 221 insertions(+) rename README.md => AWESOME_AI.md (100%) create mode 100644 AWESOME_MINIMALISM_IDEOLOGIES.md diff --git a/README.md b/AWESOME_AI.md similarity index 100% rename from README.md rename to AWESOME_AI.md diff --git a/AWESOME_MINIMALISM_IDEOLOGIES.md b/AWESOME_MINIMALISM_IDEOLOGIES.md new file mode 100644 index 0000000..4287cc0 --- /dev/null +++ b/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*.