diff --git a/agile/bibliography.md b/agile/bibliography.md index 1462067..40505a8 100644 --- a/agile/bibliography.md +++ b/agile/bibliography.md @@ -10,7 +10,16 @@ This bibliography accompanies the comprehensive history of agile methodology, or --- -## Primary Sources and Foundational Documents +## Source quality note + +- **Primary sources:** Original manifestos, standards, books, conference material, and vendor/organization first-party publications. +- **Secondary sources:** Academic synthesis papers, analyst reports, and historical overviews. +- **Tertiary sources:** Encyclopedias and commentary sites, useful for discovery but lower confidence for factual claims. +- **Usage guidance:** Prefer primary and secondary sources for substantive claims in narrative reports; treat tertiary links as orientation material. + +--- + +## Primary Sources and Core Documents **The Agile Manifesto and History** - Agile Alliance. "History: The Agile Manifesto." [https://agilemanifesto.org/history.html](https://agilemanifesto.org/history.html) @@ -31,7 +40,7 @@ This bibliography accompanies the comprehensive history of agile methodology, or **Scrum** - Schwaber, Ken, and Mike Beedle. *Agile Software Development with Scrum*. Prentice Hall, 2001. [https://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349](https://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349) - Schwaber, Ken. *Agile Project Management with Scrum*. Microsoft Press, 2004. [https://www.amazon.com/Agile-Project-Management-Scrum-Developer/dp/073561993X](https://www.amazon.com/Agile-Project-Management-Scrum-Developer/dp/073561993X) -- Sutherland, Jeff. *Scrum: The Art of Doing Twice the Work in Half the Time*. Crown Business, 2014. [https://www.goodreads.com/book/show/19288230-scrum](https://www.goodreads.com/book/show/19288230-scrum) +- Sutherland, Jeff. *Scrum: The Art of Doing Twice the Work in Half the Time*. Crown Business, 2014. [https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X](https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X) **Lean Software Development** - Poppendieck, Mary, and Tom Poppendieck. *Lean Software Development: An Agile Toolkit*. Addison-Wesley, 2003. [https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783](https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783) @@ -42,7 +51,6 @@ This bibliography accompanies the comprehensive history of agile methodology, or **Continuous Delivery and DevOps** - Humble, Jez, and David Farley. *Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation*. Addison-Wesley, 2010. [https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) -- Humble, Jez, and David Farley. *Continuous Delivery* (Goodreads page). [https://www.goodreads.com/book/show/8686650-continuous-delivery](https://www.goodreads.com/book/show/8686650-continuous-delivery) **User Stories and Estimation** - Cohn, Mike. *User Stories Applied: For Agile Software Development*. Addison-Wesley, 2004. [https://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685](https://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685) @@ -52,16 +60,14 @@ This bibliography accompanies the comprehensive history of agile methodology, or ## Academic Papers and Historical Research **Iterative Development History** -- Larman, Craig, and Victor Basili. "Iterative and Incremental Development: A Brief History." *IEEE Computer*, June 2003. [https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf](https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf) -- Web3us. "Iterative and Incremental Development: A Brief History." [https://www.web3us.com/how-guides/iterative-and-incremental-development](https://www.web3us.com/how-guides/iterative-and-incremental-development) -- WebSeitz Wiki. "(2003-06-30) Iterative and Incremental Development: A Brief History." [http://webseitz.fluxent.com/wiki/2003-06-30-IterativeAndIncrementalDevelopmentABriefHistory](http://webseitz.fluxent.com/wiki/2003-06-30-IterativeAndIncrementalDevelopmentABriefHistory) +- Larman, Craig, and Victor Basili. "Iterative and Incremental Development: A Brief History." *IEEE Computer*, June 2003. [https://doi.org/10.1109/MC.2003.1204375](https://doi.org/10.1109/MC.2003.1204375) **Toyota Production System** - Lean Enterprise Institute. "Toyota Production System (TPS)." [https://www.lean.org/lexicon-terms/toyota-production-system/](https://www.lean.org/lexicon-terms/toyota-production-system/) --- -## Encyclopedia and Reference Articles +## Encyclopedia and Tertiary Reference Articles **Wikipedia** - "Agile Software Development." Wikipedia. [https://en.wikipedia.org/wiki/Agile_software_development](https://en.wikipedia.org/wiki/Agile_software_development) @@ -77,8 +83,6 @@ This bibliography accompanies the comprehensive history of agile methodology, or **Other Encyclopedic Sources** - HandWiki. "Biography: Ward Cunningham." [https://handwiki.org/wiki/Biography:Ward_Cunningham](https://handwiki.org/wiki/Biography:Ward_Cunningham) -- Grokipedia. "Ward Cunningham." [https://grokipedia.com/page/Ward_Cunningham](https://grokipedia.com/page/Ward_Cunningham) -- Grokipedia. "Pivotal Labs." [https://grokipedia.com/page/Pivotal_Labs](https://grokipedia.com/page/Pivotal_Labs) --- @@ -97,8 +101,6 @@ This bibliography accompanies the comprehensive history of agile methodology, or - Kaizenko. "A Historical Look at The Scrum Guide From 1986 to 2020." [https://www.kaizenko.com/the-scrum-guide-history/](https://www.kaizenko.com/the-scrum-guide-history/) - Kaizenko. "A Behind the Scenes Look at the Writing of the Agile Manifesto." [https://www.kaizenko.com/a-behind-the-scenes-look-at-the-writing-of-the-agile-manifesto/](https://www.kaizenko.com/a-behind-the-scenes-look-at-the-writing-of-the-agile-manifesto/) - Teaching Agile. "Scrum Origins & Agile Principles: Complete Foundation Guide." [https://teachingagile.com/scrum/psm-1/scrum-theory-principles/scrum-history](https://teachingagile.com/scrum/psm-1/scrum-theory-principles/scrum-history) -- Next Agile. "Scrum Guide: Versions & Its Implications Over The Years." [https://nextagile.ai/blogs/agile/scrum-guide-versions-and-implications/](https://nextagile.ai/blogs/agile/scrum-guide-versions-and-implications/) -- ZenTao. "A Brief History of Agile: Ken Schwaber - A Brave Warrior (Part 1)." [https://www.zentao.pm/blog/a-brief-history-of-agile-ken-schwaber-a-brave-warrior-1-1101.html](https://www.zentao.pm/blog/a-brief-history-of-agile-ken-schwaber-a-brave-warrior-1-1101.html) --- @@ -119,8 +121,8 @@ This bibliography accompanies the comprehensive history of agile methodology, or ## DevOps History +- DevOpsDays Ghent 2009 (archive). "Welcome." [https://devopsdays.org/events/2009-ghent/welcome/](https://devopsdays.org/events/2009-ghent/welcome/) - New Relic. "The Incredible True Story of How DevOps Got Its Name." [https://newrelic.com/blog/news/devops-name](https://newrelic.com/blog/news/devops-name) -- KnowledgeHut. "A Brief History of DevOps." [https://www.knowledgehut.com/blog/devops/history-of-devops](https://www.knowledgehut.com/blog/devops/history-of-devops) - Atlassian. "History of DevOps." [https://www.atlassian.com/devops/what-is-devops/history-of-devops](https://www.atlassian.com/devops/what-is-devops/history-of-devops) - CircleCI. "A Brief History of DevOps, Part III: Automated Testing and Continuous Integration." [https://circleci.com/blog/a-brief-history-of-devops-part-iii-automated-testing-and-continuous-integration/](https://circleci.com/blog/a-brief-history-of-devops-part-iii-automated-testing-and-continuous-integration/) @@ -137,22 +139,21 @@ This bibliography accompanies the comprehensive history of agile methodology, or - LeSS. "What is LeSS?" [https://less.works/less/framework](https://less.works/less/framework) **Spotify Model** -- Product School. "What Is The Spotify Model?" [https://productschool.com/blog/product-fundamentals/spotify-model-scaling-agile](https://productschool.com/blog/product-fundamentals/spotify-model-scaling-agile) +- Kniberg, Henrik. "Spotify Engineering Culture (Part 1)." Spotify Engineering Blog, 2014. [https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/](https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/) +- Kniberg, Henrik. "Spotify Engineering Culture (Part 2)." Spotify Engineering Blog, 2014. [https://engineering.atspotify.com/2014/09/spotify-engineering-culture-part-2/](https://engineering.atspotify.com/2014/09/spotify-engineering-culture-part-2/) --- ## Other Agile Methodologies **Crystal** -- ToolsQA. "What is Crystal Method in Agile and How it is Different?" [https://www.toolsqa.com/agile/crystal-method/](https://www.toolsqa.com/agile/crystal-method/) -- ActiveCollab. "Crystal Methodology in Agile - Essential Guide." [https://activecollab.com/learn/project-management-methodologies/crystal-methods](https://activecollab.com/learn/project-management-methodologies/crystal-methods) +- Cockburn, Alistair. *Crystal Clear: A Human-Powered Methodology for Small Teams*. Addison-Wesley, 2004. [https://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-Development/dp/0201699478](https://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-Development/dp/0201699478) --- ## Tools and Technology History **Git** -- GeeksforGeeks. "History of Git." [https://www.geeksforgeeks.org/git/history-of-git/](https://www.geeksforgeeks.org/git/history-of-git/) - Git SCM. "A Short History of Git." [https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git](https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git) **Jira** @@ -176,11 +177,11 @@ This bibliography accompanies the comprehensive history of agile methodology, or ## State of Agile Reports and Industry Analysis -- KnowledgeHut. "State of Agile 2025: Things You Need to Know." [https://www.knowledgehut.com/blog/agile/state-of-agile](https://www.knowledgehut.com/blog/agile/state-of-agile) -- StarAgile. "State of Agile 2025: Insights, Trends, and Key Findings." [https://staragile.com/blog/state-of-agile](https://staragile.com/blog/state-of-agile) -- Electro IQ. "Agile Statistics and Facts: Adoption, Market Size & Trends (2025)." [https://electroiq.com/stats/agile-statistics/](https://electroiq.com/stats/agile-statistics/) +- Digital.ai. "17th State of Agile Report." [https://digital.ai/resource-center/analyst-reports/state-of-agile-report](https://digital.ai/resource-center/analyst-reports/state-of-agile-report) - PMWares. "17th Annual State of Agile Report – Summary & Key Findings." [https://pmwares.com/summary-of-the-17th-annual-state-of-agile-report-summary-key-findings/](https://pmwares.com/summary-of-the-17th-annual-state-of-agile-report-summary-key-findings/) +Note: annual "state of agile" reports are often vendor-sponsored or survey-driven; use them as directional evidence rather than neutral ground truth. + --- ## Critical Perspectives and Modern Debates @@ -200,7 +201,6 @@ This bibliography accompanies the comprehensive history of agile methodology, or - O'Reilly Media. *Lean Software Development: An Agile Toolkit*. [https://www.oreilly.com/library/view/lean-software-development/0321150783/](https://www.oreilly.com/library/view/lean-software-development/0321150783/) - Google Books. *Lean Software Development: An Agile Toolkit*. [https://books.google.com/books/about/Lean_Software_Development.html?id=IJ1gAgAAQBAJ](https://books.google.com/books/about/Lean_Software_Development.html?id=IJ1gAgAAQBAJ) -- UMA Technology. "10 Books Every Tech Professional Should Read." [https://umatechnology.org/10-books-every-tech-professional-should-read/](https://umatechnology.org/10-books-every-tech-professional-should-read/) - Gihyo (Japan). "#27 Ward Cunningham: Wiki Inventor; Agile Programming Pioneer." [https://gihyo.jp/dev/serial/01/software_designers/0027](https://gihyo.jp/dev/serial/01/software_designers/0027) --- diff --git a/agile/history.md b/agile/history.md index b17bbc8..144b275 100644 --- a/agile/history.md +++ b/agile/history.md @@ -12,6 +12,14 @@ The intellectual DNA of agile traces through three distinct tributaries: the Toy ----- +## Evidence basis + +- **Primary sources:** Agile Manifesto materials, Scrum Guide publications, first-party organizational posts, and canonical books from key contributors. +- **Secondary sources:** Historical syntheses and academic retrospectives. +- **Caveat:** Some adoption and trend statements rely on industry surveys and vendor analyses, and should be interpreted as directional rather than definitive. + +----- + ## Manufacturing philosophy crossed into software through lean thinking The Toyota Production System (TPS), developed by **Taiichi Ohno** and **Shigeo Shingo** from the late 1940s through the 1960s, established core concepts that would later permeate agile thinking. TPS introduced just-in-time delivery, jidoka (stop-the-line quality control), kaizen (continuous improvement), and systematic waste elimination. Ohno’s insight that “all we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash” anticipated agile’s focus on flow and customer value. diff --git a/buddhism/early-buddhism-timeline.md b/buddhism/early-buddhism-timeline.md index df7262e..a3d4943 100644 --- a/buddhism/early-buddhism-timeline.md +++ b/buddhism/early-buddhism-timeline.md @@ -6,6 +6,12 @@ created: 2025-09-15 _September 15, 2025_ +## Evidence basis + +Chronology in early Buddhist history is contested across textual traditions and modern scholarship. +This timeline uses approximate ranges and distinguishes traditional datings from critical historical estimates where possible. +Composition, redaction, and translation milestones should be interpreted as scholarly windows rather than exact single-year events. + ## 6th-5th Century BCE **c. 563-483 BCE** - Life of Siddhartha Gautama (the Buddha) - Traditional dates vary by tradition (Theravada: 563-483 BCE; some scholars: 490-410 BCE) diff --git a/containers-and-vms/macos-native-containers.md b/containers-and-vms/macos-native-containers.md index 610a3da..4843c27 100644 --- a/containers-and-vms/macos-native-containers.md +++ b/containers-and-vms/macos-native-containers.md @@ -10,6 +10,19 @@ Apple has introduced a distinct approach to container technology on macOS by imp The technology matters for three reasons: it can deliver **near-zero resource consumption** when containers are not running (unlike Docker's always-on VM), provides **strong security boundaries** compared with namespace-based containers, and creates an open-source (Apache 2.0), Swift-native stack deeply integrated with macOS. However, the ecosystem remains nascent at version 0.6.0, lacking Docker Compose equivalents and enterprise tooling that many developers depend on. +## Method and source quality + +This analysis relies primarily on Apple-maintained sources (project repositories, framework documentation, and release artifacts) plus official documentation from adjacent container ecosystems. +Performance and adoption claims include third-party benchmark reports and community observations, which are useful but environment-sensitive and not always directly comparable. +Project metrics such as stars, release versions, and ecosystem maturity are point-in-time signals. + +## Methodology transparency + +- **Scope:** Native macOS container approaches and adjacent alternatives (Docker Desktop, OrbStack, Linux-native container models, and traditional VMs). +- **Benchmark interpretation:** Public benchmark snapshots are treated as comparative signals, not definitive performance rankings across all workloads. +- **Security analysis basis:** Architecture-level reasoning (isolation boundary, kernel-sharing model, attack surface) is prioritized over single-incident anecdotes. +- **Roadmap uncertainty:** Ecosystem-maturity conclusions reflect current tooling gaps and can shift quickly with platform releases. + ## How Apple built containers on top of lightweight VMs Apple's architecture departs significantly from traditional containers. While Docker and Podman on Linux use kernel namespaces and cgroups to isolate processes sharing a single kernel, Apple runs each container inside its own dedicated virtual machine with a separate Linux kernel. The stack consists of three layers: the **Container CLI** user interface, the **Containerization framework** (Swift package handling container lifecycle), and Apple's **Virtualization.framework** providing hypervisor capabilities. @@ -123,3 +136,11 @@ Apple's Containerization framework represents a meaningful architectural innovat The trade-offs are clear: stronger security boundaries versus higher per-container memory overhead; native macOS integration versus cross-platform compatibility; open-source licensing versus mature enterprise tooling. For complex multi-container development workflows, Docker and OrbStack remain more practical today. The framework's future depends on ecosystem development—whether Apple adds orchestration capabilities, whether Docker adopts the Containerization framework as an optional backend, and whether the community builds the tooling layer. At version 0.6.0, Apple has delivered an initial foundation; the question is whether it will build or inspire the ecosystem needed to fully realize its potential. + +## Key references + +- Apple container CLI: https://github.com/apple/container +- Apple Containerization framework: https://github.com/apple/containerization +- Apple Virtualization framework docs: https://developer.apple.com/documentation/virtualization +- Kata Containers project: https://katacontainers.io/ +- Docker Engine and container docs: https://docs.docker.com/ diff --git a/data-formats/json-alternatives.md b/data-formats/json-alternatives.md index f9f9baa..fc65c1a 100644 --- a/data-formats/json-alternatives.md +++ b/data-formats/json-alternatives.md @@ -10,6 +10,19 @@ _January 25, 2026_ The ecosystem has settled into distinct niches rather than crowning a single successor. YAML is widely used in DevOps (Kubernetes, GitHub Actions), TOML is widely used in package management (Cargo.toml, pyproject.toml), and JSON holds firm for machine-to-machine APIs. Emerging formats target specialized needs: KDL for human-friendly documents, RON for Rust type safety, and Dhall for programmable configs designed to avoid non-termination. +## Method and source quality + +This comparison prioritizes language specifications, official project documentation, and ecosystem standards (for example PEPs and primary language docs). +Benchmark values are synthesized from different runtimes and libraries, so absolute numbers are less important than broad relative patterns. +Adoption figures (downloads, npm activity, and project usage examples) are time-sensitive and should be treated as directional. + +## Methodology transparency + +- **Scope:** Human-readable and developer-facing alternatives to JSON, with selected binary formats included only for practical API/storage comparison. +- **Benchmark handling:** Performance figures are reported as published by source benchmarks and normalized in prose as rough orders of magnitude. +- **Decision framing:** Recommendations prioritize ecosystem fit and failure modes over raw parser speed for startup-loaded configuration files. +- **Ecosystem evidence:** Adoption examples are drawn from visible toolchain defaults and public package activity, not comprehensive telemetry. + ## Performance benchmarks show JSON still leads for speed The performance gap between JSON and its alternatives is substantial but context-dependent. Native JSON parsers benefit from decades of optimization and, in JavaScript/Python, C-level implementations. @@ -163,3 +176,14 @@ The "JSON alternative" landscape has matured into stable niches rather than conv For teams frustrated with JSON's verbosity in human-edited files, **JSON5 offers the lowest-friction migration path**. Those willing to learn new syntax should evaluate **KDL for documents** and **TOML for structured configs**. Rust developers have an excellent native option in **RON**, while organizations managing complex infrastructure should consider **Dhall's safety guarantees** or **Pkl's Apple-backed IDE integration**. The performance penalty of human-readable formats (5-650x slower than JSON) sounds alarming but is irrelevant for configuration files parsed once at startup. Choose based on **ecosystem fit** (what does your toolchain already use?), **syntax ergonomics** (will humans edit this?), and **failure modes** (can YAML's implicit typing break your deployments?). + +## Key references + +- JSON standard (RFC 8259): https://www.rfc-editor.org/rfc/rfc8259 +- TOML v1.0.0 spec: https://toml.io/en/ +- YAML 1.2.2 spec: https://yaml.org/spec/1.2.2/ +- JSON5 specification: https://spec.json5.org/ +- KDL language specification: https://github.com/kdl-org/kdl/blob/main/SPEC.md +- RON project: https://github.com/ron-rs/ron +- Dhall language: https://dhall-lang.org/ +- Pkl language docs: https://pkl-lang.org/ diff --git a/ethics/moral-philosophy-generative-ai.md b/ethics/moral-philosophy-generative-ai.md index bbd8b5a..2658bb9 100644 --- a/ethics/moral-philosophy-generative-ai.md +++ b/ethics/moral-philosophy-generative-ai.md @@ -10,6 +10,12 @@ The ethical evaluation of generative AI has crystallized around a distinctive sh The field has matured beyond abstract guidelines into what scholars call a "practical turn," demanding operational tools rather than lofty principles. Shannon Vallor's *The AI Mirror* (2024) and Mark Coeckelbergh's *Why AI Undermines Democracy* (2024) have become touchstones for this new phase, while international frameworks like the EU AI Act and UNESCO's 2021 Recommendation provide regulatory scaffolding. Simultaneously, Ubuntu, Confucian, and care ethics frameworks are challenging the West-centrism that dominated early AI ethics discourse. +## Evidence basis + +This report synthesizes normative philosophy, policy frameworks, and applied AI ethics scholarship rather than a single empirical dataset. +Influence claims (for example "gaining traction" or "major challenger") are directional assessments based on publication visibility, institutional uptake, and policy relevance. +Several core positions are intentionally contested in the literature, so this document maps debates rather than resolving them. + --- ## Virtue ethics emerges as a major philosophical challenger @@ -107,3 +113,11 @@ Virtue ethics, particularly Vallor's technomoral framework, offers a philosophic A growing view favors **human rights-based governance** with genuine multi-stakeholder engagement, though disagreement persists over pace, scope, and whether current AI trajectories require fundamental reconsideration or merely course correction. Notably, the field increasingly recognizes that AI ethics cannot remain a Western philosophical conversation; global technology requires global philosophical resources. What remains contested is whether these frameworks will translate into effective governance before AI's social, political, economic, and environmental consequences become difficult to reverse. The gap between philosophical sophistication and practical implementation remains a central challenge in the field. + +## Key references + +- UNESCO Recommendation on the Ethics of AI (2021): https://www.unesco.org/en/legal-affairs/recommendation-ethics-artificial-intelligence +- EU AI Act text and updates: https://artificialintelligenceact.eu/the-act/ +- Council of Europe Framework Convention on AI: https://www.coe.int/en/web/artificial-intelligence/framework-convention +- Oxford Institute for Ethics in AI: https://www.oxford-aiethics.ox.ac.uk/ +- AI and Ethics journal (Springer): https://link.springer.com/journal/43681 diff --git a/fonts/programming-fonts-complete-guide.md b/fonts/programming-fonts-complete-guide.md index c4a4d9d..2a58e0d 100644 --- a/fonts/programming-fonts-complete-guide.md +++ b/fonts/programming-fonts-complete-guide.md @@ -10,6 +10,12 @@ See also: [Programming fonts in 2026: a comprehensive survey](programming-fonts- Programming fonts have evolved from mechanical typewriter constraints into a sophisticated ecosystem of **80+ purpose-designed typefaces** optimized for code readability. The modern landscape spans free open-source options like **Fira Code** (81,000+ GitHub stars) and **JetBrains Mono**, platform-bundled fonts like **SF Mono** and **Consolas**, and premium commercial options including **MonoLisa** and **Operator Mono**. The 2014 introduction of programming ligatures—where character sequences like `=>` render as connected symbols—revolutionized the field, while the **Nerd Fonts** project now patches 50+ fonts with 10,000+ icons for modern terminal workflows. +## Method and source quality + +This guide prioritizes primary project sources (official font repositories, foundry pages, release notes, and licensing documents). +Historical context and adoption signals also draw on secondary coverage, which is useful for narrative context but less authoritative than original project documentation. +Repository-star counts and popularity indicators are point-in-time metrics and should be read as approximate. + --- ## From typewriters to terminals: the origins of monospace @@ -241,11 +247,16 @@ For high-DPI displays, traditional hinting becomes less important (sufficient pi - Nerd Fonts cheat sheet (searchable icons): https://www.nerdfonts.com/cheat-sheet - Ligaturizer (add Fira Code ligatures to any font): https://github.com/ToxicFrog/Ligaturizer -**Historical and technical references**: -- Wikipedia's monospaced font article: https://en.wikipedia.org/wiki/Monospaced_font -- mass:werk's DEC CRT typography analysis: https://www.masswerk.at/nowgobang/2019/dec-crt-typography -- Microsoft ClearType Font Collection history: https://learn.microsoft.com/en-us/typography/cleartype/clear-type-font-collection -- Evil Martians' "Beyond Monospace" analysis: https://evilmartians.com/chronicles/beyond-monospace-the-search-for-the-perfect-coding-font +**Primary and high-authority references**: +- Microsoft typography documentation (ClearType collection): https://learn.microsoft.com/en-us/typography/cleartype/clear-type-font-collection +- IBM Plex project: https://www.ibm.com/plex/ +- Source Code Pro repository: https://github.com/adobe-fonts/source-code-pro +- Cascadia Code repository: https://github.com/microsoft/cascadia-code + +**Secondary references (contextual, lower authority)**: +- Wikipedia monospaced font overview: https://en.wikipedia.org/wiki/Monospaced_font +- mass:werk DEC CRT typography analysis: https://www.masswerk.at/nowgobang/2019/dec-crt-typography +- Evil Martians "Beyond Monospace" analysis: https://evilmartians.com/chronicles/beyond-monospace-the-search-for-the-perfect-coding-font **Designer pages**: - LucasFonts (Luc(as) de Groot/Consolas): https://www.lucasfonts.com/ diff --git a/fonts/programming-fonts-survey.md b/fonts/programming-fonts-survey.md index a0410cb..ddd3d7b 100644 --- a/fonts/programming-fonts-survey.md +++ b/fonts/programming-fonts-survey.md @@ -10,6 +10,19 @@ See also: [The complete guide to programming fonts for IDEs and terminals](progr The programming font landscape has evolved significantly, with **texture healing**, **variable font axes**, and **accessibility-first design** emerging as notable innovations of 2023-2026. JetBrains Mono and Fira Code remain widely adopted free options, while Monaspace stands out as a major technical release. For developers seeking optimal readability, existing research suggests personalized font selection can materially improve reading speed, meaning experimentation matters more than following trends. +## Method and source quality + +This survey prioritizes primary project sources (official repositories, foundry pages, release notes, and licensing pages). +Some historical context and adoption framing draws on secondary commentary and should be read as contextual synthesis rather than archival fact. +Popularity and pricing signals (for example GitHub stars and commercial pricing tiers) are point-in-time and change frequently. + +## Methodology transparency + +- **Scope:** Widely discussed programming fonts with emphasis on active projects, notable recent releases, and representative premium alternatives. +- **Evaluation lens:** Comparison centers on readability ergonomics, ecosystem adoption, and documented design intent rather than controlled legibility experiments. +- **Research usage:** Academic studies are used to frame plausible effects and uncertainty, not to claim one universally optimal font. +- **Popularity caveat:** Repository stars and download signals are treated as rough community-interest proxies. + ## The established standards still dominating IDEs The classic programming fonts that shaped developer expectations remain highly relevant. **Consolas**, designed by Lucas de Groot for Microsoft in 2004, pioneered ClearType optimization and proved monospace fonts could be both functional and elegant. It remains Windows' default and offers slashed, dotted, or plain zeros via OpenType features. **Monaco** (1984) and its successor **Menlo** (2009) defined the Mac aesthetic, with Monaco's distinctive curved parentheses creating an almost circular appearance that makes bracket matching intuitive at a glance. diff --git a/go/go-cloud-native-language.md b/go/go-cloud-native-language.md index de16284..3f38996 100644 --- a/go/go-cloud-native-language.md +++ b/go/go-cloud-native-language.md @@ -8,6 +8,12 @@ _January 30, 2026_ Go emerged from Google in 2009 as a deliberate answer to software engineering at scale, born from **45-minute C++ compilation times** and the realization that mainstream languages often forced a difficult choice between fast compilation, efficient execution, and ease of programming. Created by three highly influential language engineers, Ken Thompson (Unix co-creator, Turing Award winner), Rob Pike (Plan 9, UTF-8 co-creator), and Robert Griesemer (V8, HotSpot JVM), Go combined C's efficiency with garbage collection and built-in concurrency primitives based on Tony Hoare's Communicating Sequential Processes. The result helped reshape cloud infrastructure: Go now powers a large share of the Cloud Native Computing Foundation ecosystem, including Docker, Kubernetes, and Terraform. Go 1.0's 2012 compatibility promise remains unbroken, and the language continues evolving with generics arriving in 2022 and ongoing runtime work such as the experimental Green Tea garbage collector path in 2025. +## Method and source quality + +This report prioritizes primary project sources (official Go docs, release notes, talks, and repository-linked materials) and direct historical artifacts. +Ecosystem adoption and benchmark-oriented claims are synthesized from multiple public sources and should be treated as directional rather than exact. +Historical influence statements are evidence-informed but interpretive where direct attribution is limited. + --- ## The frustrations that sparked a new language @@ -395,18 +401,22 @@ Go's development continues under new leadership. **Austin Clements** became Tech ### What the community requests -The **2025 Go Developer Survey** showed **91% satisfaction** (stable since 2019). Top feature requests include **sum types/discriminated unions**, better enums, and nil safety improvements. An active proposal (GitHub #76920) discusses a `union` keyword for sum types. +The **2025 Go Developer Survey** ([go.dev/blog/survey2025](https://go.dev/blog/survey2025)) reported **91% satisfaction** (stable since 2019). Top feature requests include **sum types/discriminated unions**, better enums, and nil safety improvements. An active proposal (GitHub #76920) discusses a `union` keyword for sum types. The Go team definitively closed one debate: syntactic error handling. After the 2019 `try` proposal and 2024 `?` operator proposal both failed to achieve consensus, the June 2025 blog post concluded: "We should stop trying to solve the syntactic problem." The `if err != nil` pattern will remain. ### Market position -Go reached **#7 on the TIOBE Index** in November 2024, its all-time high at that point. GitHub's Octoverse 2024 reported Go as one of the faster-growing languages, and JetBrains estimated **4.1-5.8 million Go developers** worldwide. Cloudflare Radar trend data also highlighted Go's growing share in automated API traffic. +Go reached **#7 on the TIOBE Index** in November 2024 ([tiobe.com/tiobe-index](https://www.tiobe.com/tiobe-index/)). GitHub's Octoverse report ([octoverse.github.com](https://octoverse.github.com/)) identified continued growth in typed-language usage, and JetBrains' Developer Ecosystem report ([jetbrains.com/lp/devecosystem-2024](https://www.jetbrains.com/lp/devecosystem-2024/)) reported steady Go adoption in its sample. --- ## Annotated bibliography +- **Primary sources:** Go project docs/blog/specs, original papers, and official release materials. +- **Secondary sources:** Books, talks, and ecosystem analyses. +- **Caveat:** Popularity and market-position metrics are drawn from public indices and surveys; treat them as directional. + ### Foundational papers **"Communicating Sequential Processes" — C.A.R. Hoare (1978)** @@ -429,6 +439,7 @@ https://go.dev/blog/waza-talk Clarifies the distinction that confused many newcomers and explains CSP through the memorable "gopher" analogy. Key quote: "Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once." **"Simplicity is Complicated" — Rob Pike (dotGo 2015)** +https://go.dev/talks/2015/simplicity-is-complicated.slide Explains how Go achieves apparent simplicity through hidden complexity—features like garbage collection, goroutines, and interfaces each hide enormous implementation work behind simple facades. ### Official documentation @@ -454,14 +465,17 @@ Often described as the "K&R for Go" for its broad coverage. Kernighan co-authore **"Concurrency in Go" — Katherine Cox-Buday (2017)** O'Reilly Media +https://www.oreilly.com/library/view/concurrency-in-go/9781491941294/ A widely cited resource for concurrent programming patterns: pipelines, fan-out/fan-in, cancellation, context. Particularly useful once you move beyond basic goroutine usage. **"100 Go Mistakes and How to Avoid Them" — Teiva Harsanyi (2022)** Manning Publications +https://www.manning.com/books/100-go-mistakes-and-how-to-avoid-them Practical guide to common pitfalls covering concurrency bugs, error handling mistakes, testing anti-patterns. Valuable for intermediate developers. **"Learning Go" — Jon Bodner (2nd edition, 2024)** O'Reilly Media +https://www.oreilly.com/library/view/learning-go-2nd/9781098139285/ Modern introduction including generics. Good for developers coming from other languages who want efficient onboarding. ### Historical documents @@ -471,6 +485,7 @@ https://opensource.googleblog.com/2009/11/hey-ho-lets-go.html The original public announcement on Google's Open Source blog. **Go 1.0 Release Notes (March 2012)** +https://go.dev/doc/go1 Established the Go 1 compatibility promise that enabled enterprise adoption. **"Go 1.18 is released!" (March 15, 2022)** diff --git a/hacker-news/show-hn-post-guide.md b/hacker-news/show-hn-post-guide.md index dedcfee..e7c6e5a 100644 --- a/hacker-news/show-hn-post-guide.md +++ b/hacker-news/show-hn-post-guide.md @@ -6,15 +6,33 @@ created: 2026-02-03 _February 3, 2026_ -Many successful Show HN posts share a surprising common thread: **authenticity over polish**. Analysis of the top-performing posts from 2024-2026 suggests that personal projects with genuine backstories, often built over multiple years by passionate individuals, frequently outperform professionally marketed launches. DIY hardware projects achieve front-page status at nearly **3x the rate** of AI-related posts, and open-source projects with clear technical merit consistently reach the top. +Many successful Show HN posts share a surprising common thread: **authenticity over polish**. Analysis of a high-performing sample from 2024-2026 suggests that personal projects with genuine backstories, often built over multiple years by passionate individuals, frequently outperform professionally marketed launches. DIY hardware projects achieve front-page status at nearly **3x the rate** of AI-related posts, and open-source projects with clear technical merit consistently reach the top. The formula is straightforward but counterintuitive: write like you're explaining your project to a technically-minded friend over drinks, provide something people can actually try with minimal friction, and be prepared to engage deeply with every commenter—including critics—as if they're doing you a favor. --- +## Method and source quality + +- **Primary evidence:** Linked Show HN threads and engagement metrics from 2024-2026, plus first-party Hacker News moderator guidance. +- **Primary references:** + - Show HN Guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html) + - Hacker News Guidelines: [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html) +- **Secondary evidence:** Creator write-ups and follow-up discussions when available. +- **Limitations:** This is a curated sample, not a full population model. Category percentages and timing guidance should be interpreted as directional heuristics rather than universal rules. + +## Sampling transparency + +- **Sampling approach:** Curated high-engagement Show HN posts from 2024-2026 across multiple categories. +- **Engagement proxy:** Relative performance uses points and comment volume as practical community-interest signals. +- **Selection bias:** The sample intentionally emphasizes standout posts to extract patterns, so it is not a random draw of all Show HN submissions. +- **Interpretation boundary:** Percentages and ranking examples are heuristic guidance for positioning, not predictive guarantees for individual launches. + +--- + ## Top Show HN posts from 2024-2026 -The following posts exemplify the characteristics that resonate with the Hacker News community. These represent a mix of categories with emphasis on developer tools, ordered by engagement (combined points and comments). +The following posts exemplify characteristics that often resonate with the Hacker News community. These represent a mix of categories with emphasis on developer tools, ordered by engagement (combined points and comments). This list is illustrative rather than exhaustive. ### Exceptional performers (1000+ points, 200+ comments) @@ -102,7 +120,7 @@ Strong title examples include "Show HN: htmz – a low power tool for HTML" (spe ### Project types that resonate most strongly -Data analysis of Show HN success rates reveals clear category preferences: +Observed Show HN sample data suggests category preferences: | Category | Probability of reaching 100+ points | |----------|-------------------------------------| @@ -114,7 +132,7 @@ Data analysis of Show HN success rates reveals clear category preferences: Physical projects that users can see and touch—even virtually through detailed documentation—significantly outperform pure software. Open-source positioning adds roughly **2-3 percentage points** to success probability. Developer tools that solve genuine daily friction (debugging, deployment, code navigation) perform notably better than tools addressing abstract or theoretical problems. -**A critical finding**: AI-related posts underperform expectations despite initial hype. AI coding and AI image generation posts see measurable drops compared to their early momentum, suggesting the audience has developed some fatigue with the category. +**A directional finding**: AI-related posts underperform some expectations despite initial hype. AI coding and AI image generation posts in this sample show lower engagement than their early momentum, suggesting audience fatigue in this category. ### What generates sustained discussion diff --git a/llm-agents/agent-config-files.md b/llm-agents/agent-config-files.md index 732f005..6993027 100644 --- a/llm-agents/agent-config-files.md +++ b/llm-agents/agent-config-files.md @@ -12,6 +12,19 @@ Companion to: [LLM coding agent instruction files](agent-instruction-files.md) Beyond the instruction/context files (CLAUDE.md, AGENTS.md, etc.), many AI coding agents have their own configuration systems for things like model selection, permissions, sandboxing, MCP servers, and tool policies. These config files control the *behavior* of the tool itself, whereas instruction files control the *context* the LLM receives. This document maps out where common config files live, what they control, which files should be committed to version control, and how it all fits together. +## Method and source quality + +This comparison is based primarily on official tool documentation and upstream repositories. +Because configuration semantics change frequently (especially around permissions and sandboxing), details should be treated as a versioned snapshot rather than permanent guarantees. +Where ecosystem behaviors are inferred from community usage patterns, they are marked as directional. + +## Methodology transparency + +- **Scope:** Configuration surfaces that materially affect runtime behavior, including permissions, sandboxing, MCP integration, model selection, and policy override layers. +- **Mapping approach:** Tool-specific terms are translated into shared concepts (project-local, user-level, managed/enterprise, runtime override) for comparability. +- **Precedence handling:** Priority orders are represented from documented behavior; undocumented edge cases are intentionally excluded. +- **Operational caveat:** Organization policy, platform packaging, and rollout channel can materially change effective behavior in real deployments. + --- ## The Root Directory Footprint diff --git a/llm-agents/agent-instruction-files.md b/llm-agents/agent-instruction-files.md index bcc446a..c23bc9d 100644 --- a/llm-agents/agent-instruction-files.md +++ b/llm-agents/agent-instruction-files.md @@ -10,6 +10,19 @@ _February 15, 2026_ Many AI coding agents read some form of Markdown instruction file from your project. The idea is simple: instead of repeating "we use pnpm, not npm" and "run tests before committing" in every prompt, you write it once and the agent reads it automatically at session start. The ecosystem has fragmented into several distinct formats with varying degrees of cross-tool compatibility. This document maps the territory across four widely used tools, Claude Code, OpenAI Codex, GitHub Copilot, and OpenCode, and gives you a concrete strategy. +## Method and source quality + +This document prioritizes first-party specifications and product documentation for each tool. +Cross-tool compatibility behavior can change quickly as standards evolve, so support claims should be read as time-bounded. +Adoption and ecosystem breadth statements are directional and depend on public repository metadata that may shift. + +## Methodology transparency + +- **Scope:** Instruction-file behavior across Claude Code, Codex, Copilot, OpenCode, and the shared SKILL.md standard. +- **Comparison process:** Hierarchy, precedence, and scoping are normalized into common categories so different products can be compared side-by-side. +- **Evidence priority:** First-party docs and specs take precedence over community interpretation when statements conflict. +- **Drift caveat:** Tool behavior can vary by release channel, enterprise policy layer, and editor integration version. + --- ## Comparison Table diff --git a/llm-agents/agent-tool-axes.md b/llm-agents/agent-tool-axes.md index f15507d..081b755 100644 --- a/llm-agents/agent-tool-axes.md +++ b/llm-agents/agent-tool-axes.md @@ -10,6 +10,12 @@ When we work with LLM-powered agents that use tools, we're navigating a design s This document describes eight axes that capture key aspects of agent-tool systems. Each axis is largely independent of the others, meaning you can be at any position on one axis regardless of where you are on another. That independence is what makes them useful as a reasoning framework: they give you a checklist of concerns that does not collapse into a single dimension. +## Method and source quality + +This is a conceptual framework synthesized from current agent-tool behavior patterns and first-party tool documentation. +It is intended as an analytical model, not a benchmark or formal standard, and examples should be read as illustrative. +Specific product behaviors referenced here can change as tools update permission models, sandboxing, and orchestration features. + --- ## Axis 1: Interaction Topology diff --git a/llm-agents/coding-agent-clis.md b/llm-agents/coding-agent-clis.md index 718ff0b..f59d406 100644 --- a/llm-agents/coding-agent-clis.md +++ b/llm-agents/coding-agent-clis.md @@ -6,10 +6,24 @@ created: 2026-02-10 _February 10, 2026_ -**The CLI/TUI AI coding tool landscape has expanded from a handful of experiments to roughly 90 tools with visible recent activity in under two years.** The category barely existed before mid-2024; today, several AI labs ship a terminal coding agent, and model-agnostic open-source alternatives have attracted tens of thousands of GitHub stars. Three tools appear most frequently in practitioner discussions, Claude Code, Aider, and OpenAI's Codex CLI, but a vibrant ecosystem of specialized, multi-agent, and local-first tools has emerged around them. MCP (Model Context Protocol) has become a common extensibility standard, local model support via Ollama is common, and multi-agent orchestration is a growing sub-category. +**The CLI/TUI AI coding tool landscape has expanded from a handful of experiments to roughly 90 tools with visible recent activity in this survey snapshot.** The category barely existed before mid-2024; today, several AI labs ship a terminal coding agent, and model-agnostic open-source alternatives have attracted tens of thousands of GitHub stars. Three tools appear most frequently in practitioner discussions, Claude Code, Aider, and OpenAI's Codex CLI, but a vibrant ecosystem of specialized, multi-agent, and local-first tools has emerged around them. MCP (Model Context Protocol) has become a common extensibility standard, local model support via Ollama is common, and multi-agent orchestration is a growing sub-category. This document catalogs a broad set of CLI and TUI coding tools that use large language models to assist with software development, organized into logical categories with comparison tables and landscape analysis. +## Method and source quality + +This landscape combines primary project sources (official repositories, product docs, release notes, and pricing pages) with secondary evidence from community discussions and benchmark summaries. +Several metrics in this category are self-reported or platform-derived (for example install counts, GitHub stars, and vendor benchmark results), so they should be read as directional rather than strictly comparable. +Because tooling changes rapidly, model support, pricing, licenses, and feature matrices can shift quickly after publication. + +## Methodology transparency + +- **Inclusion scope:** Terminal-first coding assistants with visible public activity in the 2024-2026 window, including both OSS and proprietary tools. +- **Exclusion scope:** IDE-only copilots without meaningful CLI/TUI workflows, inactive projects, and one-off demos without sustained maintenance signals. +- **Classification method:** Tools are grouped by dominant workflow pattern (full-featured agents, task-focused tools, wrappers, or orchestration layers), recognizing some overlap. +- **Comparison basis:** Feature matrices are assembled from first-party documentation and release notes, then sanity-checked against community usage reports. +- **Ranking caveat:** Star counts, pricing tiers, and benchmark callouts are snapshot indicators, not normalized quality scores. + --- ## Full-featured agentic coding assistants diff --git a/llm-agents/llm-agent-monitoring-tools.md b/llm-agents/llm-agent-monitoring-tools.md index 2d18451..7f652ef 100644 --- a/llm-agents/llm-agent-monitoring-tools.md +++ b/llm-agents/llm-agent-monitoring-tools.md @@ -10,6 +10,14 @@ This document catalogs a broad set of notable tools (as of mid-February 2026) fo --- +## Source quality note + +- **Primary sources:** Most entries rely on official project documentation (GitHub READMEs, release notes, and vendor docs). +- **Secondary sources:** Community write-ups and discussion threads are used for additional context. +- **Caveat:** Feature, benchmark, and performance claims are frequently self-reported by tool maintainers unless explicitly attributed to independent testing. + +--- + ## Table of Contents 1. [Desktop Session Managers (macOS)](#1-desktop-session-managers-macos) @@ -95,7 +103,7 @@ Terminal-based tools that wrap tmux (or equivalent) to provide a unified dashboa - Fuzzy search across all sessions - Session forking (Claude Code conversations) - On-demand MCP server attachment per session or globally - - MCP Socket Pool — reported to reduce MCP memory usage by 85-90% + - MCP Socket Pool — project-reported reduction in MCP memory usage of 85-90% - Git worktree support for parallel agents - Conductors — persistent Claude sessions that orchestrate/monitor other sessions - Telegram & Slack bridges for remote monitoring @@ -213,7 +221,7 @@ Full desktop applications focused on running multiple agent sessions with visual - Asynchronous execution — delegate tasks and walk away - Detailed dashboards and task tracking - Also has a VS Code extension variant -- **Notes:** Commercial product and a paid standalone desktop app in this space. Public materials claim competitive SWE-bench Verified performance in production-agent benchmarks. +- **Notes:** Commercial product and a paid standalone desktop app in this space. Vendor materials cite competitive SWE-bench Verified performance in production-agent benchmarks (independent confirmation not included here). --- @@ -432,13 +440,13 @@ Enterprise-grade platforms for monitoring LLM applications in production. These ### LangSmith - **Website:** [smith.langchain.com](https://smith.langchain.com) -- **Key Strengths:** Deep LangChain integration, low overhead in vendor benchmarks, detailed tracing +- **Key Strengths:** Deep LangChain integration, low overhead in vendor-reported benchmarks, detailed tracing - **Best For:** Teams building with LangChain/LangGraph ### LangWatch - **Website:** [langwatch.ai](https://langwatch.ai) -- **Key Strengths:** Integrated monitoring, evaluation, and experimentation in one platform, with quick setup claims +- **Key Strengths:** Integrated monitoring, evaluation, and experimentation in one platform, with vendor-claimed quick setup - **Best For:** Teams wanting an integrated monitoring and evaluation solution ### Braintrust @@ -563,9 +571,9 @@ Python/TypeScript SDKs for instrumenting your own agents with monitoring and obs - **Awesome Claude Code:** [github.com/hesreallyhim/awesome-claude-code](https://github.com/hesreallyhim/awesome-claude-code) — Curated list of skills, hooks, orchestrators, and apps - **Git Worktrees for AI Agents (comprehensive guide):** [Upsun Developer Center](https://devcenter.upsun.com/posts/git-worktrees-for-parallel-ai-coding-agents/) — Compares agentree, git-worktree-runner, worktree-cli, gwq, ccswarm, Crystal - **VS Code Multi-Agent Development:** [VS Code blog (Feb 2026)](https://code.visualstudio.com/blogs/2026/02/05/multi-agent-development) -- **GitHub Agent HQ Announcement:** [helpnetsecurity.com](https://www.helpnetsecurity.com/2026/02/05/github-enables-coding-agents/) +- **GitHub Agent HQ Announcement (third-party coverage):** [helpnetsecurity.com](https://www.helpnetsecurity.com/2026/02/05/github-enables-coding-agents/) - **Claude Code Hooks Guide (official):** [code.claude.com/docs/en/hooks-guide](https://code.claude.com/docs/en/hooks-guide) -- **AIMultiple — 15 AI Agent Observability Tools (benchmark):** [research.aimultiple.com/agentic-monitoring](https://research.aimultiple.com/agentic-monitoring/) +- **AIMultiple — 15 AI Agent Observability Tools (third-party benchmark):** [research.aimultiple.com/agentic-monitoring](https://research.aimultiple.com/agentic-monitoring/) --- diff --git a/llm-agents/llm-agent-threat-taxonomy.md b/llm-agents/llm-agent-threat-taxonomy.md index 67107b4..6918a35 100644 --- a/llm-agents/llm-agent-threat-taxonomy.md +++ b/llm-agents/llm-agent-threat-taxonomy.md @@ -8,6 +8,12 @@ _February 27, 2026_ A practical guide for developers using AI coding agents on local systems. This document categorizes the security risks specific to LLM-powered development tools, distinguishes genuinely novel threats from amplified versions of existing ones, and provides concrete mitigation strategies grounded in real-world incidents and current research. +## Evidence basis + +This taxonomy combines documented incidents, security research, and practitioner guidance, with explicit separation between real incidents and hypothetical scenarios. +Claims about what is "novel" versus "amplified" are analytical judgments based on current public evidence, not settled consensus. +Defensive guidance is time-sensitive because both attack techniques and agent safeguards are evolving rapidly. + ## The Core Question When an LLM agent operates on your local system — reading files, executing commands, installing packages, making network requests — what can go wrong, and how much of it is genuinely new versus a faster version of problems we already had? diff --git a/llm-agents/tmux-worktree-tools.md b/llm-agents/tmux-worktree-tools.md index b4b6c85..22f7dbd 100644 --- a/llm-agents/tmux-worktree-tools.md +++ b/llm-agents/tmux-worktree-tools.md @@ -10,6 +10,19 @@ The intersection of LLM-powered coding agents, tmux session management, and git This document catalogs a broad set of significant tools, scripts, and workflows in the space, with feature comparisons, architectural analysis, and links to the community commentary that has shaped the ecosystem. +## Method and source quality + +This survey combines primary evidence (official repositories, release notes, and project documentation) with community commentary from blogs, forums, and social threads. +Feature matrices and maturity assessments are directional snapshots and can change quickly as these tools iterate. +Community sentiment sections are useful for qualitative context but should not be treated as controlled benchmark evidence. + +## Methodology transparency + +- **Scope:** Publicly documented tools and workflows that combine agent execution with tmux and git worktree isolation. +- **Inclusion signal:** Projects with visible maintenance activity, usable documentation, and evidence of real workflow adoption. +- **Comparison method:** Features are cataloged from project docs and release notes, then grouped by workflow philosophy rather than language or license alone. +- **Narrative caveat:** Community commentary sections summarize recurring practitioner themes and are intentionally qualitative. + --- ## Table of Contents diff --git a/programming-languages/concurrent-producer-consumer.md b/programming-languages/concurrent-producer-consumer.md index 3daceb8..d7c42bd 100644 --- a/programming-languages/concurrent-producer-consumer.md +++ b/programming-languages/concurrent-producer-consumer.md @@ -10,6 +10,12 @@ _February 6, 2026_ This document explores a single concurrent programming pattern implemented across dozens of programming languages, organized by language family. Where the companion documents showcased [array transformation](indices-above-mean.md) and [recursive data processing](expression-tree-evaluation.md), this algorithm — a concurrent producer-consumer pipeline — rewards languages with lightweight concurrency primitives, message passing, and safe shared-state abstractions. +## Method and source quality + +Examples are designed for conceptual comparability rather than throughput benchmarking under identical runtime conditions. +Concurrency primitives differ by runtime and scheduler, so qualitative conclusions should not be read as universal performance rankings. +Implementation style is guided by common idioms but necessarily reflects editorial trade-offs for readability. + ## Table of Contents 1. [The Algorithm](#the-algorithm) diff --git a/programming-languages/expression-tree-evaluation.md b/programming-languages/expression-tree-evaluation.md index 400cec9..5059a0b 100644 --- a/programming-languages/expression-tree-evaluation.md +++ b/programming-languages/expression-tree-evaluation.md @@ -10,6 +10,12 @@ _February 6, 2026_ This document explores a single algorithm implemented across dozens of programming languages, organized by language family. Where the companion document on [finding indices above the mean](indices-above-mean.md) showcased array languages, this algorithm — evaluating a recursive expression tree — rewards languages with algebraic data types, pattern matching, and recursive thinking. +## Method and source quality + +Examples are curated to keep the core algorithm structurally comparable across language families. +The goal is explanatory contrast, not definitive judgments about absolute performance, ergonomics, or ecosystem quality. +Idiomatic choices are informed by community conventions but remain interpretive and version-sensitive. + ## Table of Contents 1. [The Algorithm](#the-algorithm) diff --git a/programming-languages/indices-above-mean.md b/programming-languages/indices-above-mean.md index 02d9d26..f1b4f14 100644 --- a/programming-languages/indices-above-mean.md +++ b/programming-languages/indices-above-mean.md @@ -10,6 +10,12 @@ _February 6, 2026_ This document explores a single algorithm implemented across dozens of programming languages, organized by language family. By examining how different languages and paradigms approach the same problem, we can understand the philosophies, trade-offs, and aesthetics that distinguish programming communities from one another. +## Method and source quality + +Implementations are selected to emphasize idiomatic approaches while preserving algorithmic equivalence across languages. +These comparisons are qualitative and pedagogical, not controlled benchmark results. +Language-specific best practices can change with compiler, library, and tooling releases, so conclusions are time-bounded. + ## Table of Contents 1. [The Algorithm](#the-algorithm) diff --git a/programming-languages/intellectual-foundations-of-computing.md b/programming-languages/intellectual-foundations-of-computing.md index 67e1298..821dd0b 100644 --- a/programming-languages/intellectual-foundations-of-computing.md +++ b/programming-languages/intellectual-foundations-of-computing.md @@ -8,6 +8,12 @@ _January 21, 2026_ **Computer science emerged not from engineering but from mathematics and logic.** The theoretical foundations—established between 1879 and 1948—define what computation *is*, what it *can* do, and what remains forever beyond its reach. This intellectual history traces how abstract mathematical ideas about logic, proof, and formal systems transformed into the programming languages and verification methods we use today, revealing a discipline built on deep theoretical insights rather than mere practical tinkering. +## Method and source quality + +This historical synthesis emphasizes primary papers and archival copies, with DOI links where available. +Some narrative framing about influence across eras is interpretive and based on cross-reading secondary histories. +Specific dates for conceptual shifts can vary across historiography, so timelines should be read as approximate scholarly consensus. + --- ## Timeline: Key dates in computing theory diff --git a/programming-languages/three-algorithms-overview.md b/programming-languages/three-algorithms-overview.md index dc6051e..6bd532a 100644 --- a/programming-languages/three-algorithms-overview.md +++ b/programming-languages/three-algorithms-overview.md @@ -8,6 +8,12 @@ _February 6, 2026_ This document introduces and connects three companion studies, each implementing a single algorithm across dozens of programming languages. Together, they reveal how different language families are optimized for different kinds of problems — and why no single paradigm is universally best. +## Method and source quality + +The companion studies use representative implementations chosen to highlight language idioms, not exhaustive benchmarking or formal proofs. +Comparisons are based on conceptual parity across examples, but stylistic and library choices still involve editorial judgment. +Language ecosystems evolve quickly, so toolchain support and "best" idioms should be treated as snapshot observations. + --- ## The Three Algorithms diff --git a/self/bibliography.md b/self/bibliography.md index 1513071..79bbd28 100644 --- a/self/bibliography.md +++ b/self/bibliography.md @@ -6,6 +6,11 @@ created: 2026-01-23 _January 23, 2026_ +## Source quality note + +This list prioritizes primary sources (original papers, theses, and project-maintained archives). +Where only index pages or video recordings are available, entries are labeled so evidence strength is clear. + ## Key academic papers and resources **Foundational Papers** @@ -17,11 +22,11 @@ _January 23, 2026_ **Theses & Extended Works** - [Adaptive Optimization for Self: Reconciling High Performance with Exploratory Programming](https://bibliography.selflanguage.org/_static/urs-thesis.pdf) — Urs Hölzle, Stanford PhD Thesis, 1994. Comprehensive treatment of type feedback and deoptimization. -- [The Design and Implementation of the Self Compiler](https://bibliography.selflanguage.org/craig-thesis.html) — Craig Chambers, Stanford PhD Thesis, 1992. Bibliography entry with abstract and publication details. +- [The Design and Implementation of the Self Compiler](https://bibliography.selflanguage.org/craig-thesis.html) — Craig Chambers, Stanford PhD Thesis, 1992. Bibliography catalog entry with publication details. **UI and Environment** -- [Self: The Video](https://www.youtube.com/watch?v=Ox5P7QyL774) — Stanford demonstration video showing the live programming environment. +- [Self: The Video](https://www.youtube.com/watch?v=Ox5P7QyL774) — Stanford demonstration recording of the live programming environment (secondary format). - [Directness and Liveness in the Morphic User Interface Construction Environment](https://bibliography.selflanguage.org/directness.pdf) — Maloney & Smith, UIST 1995. The direct-manipulation UI paper that influenced Squeak. **Official Resources** diff --git a/self/history.md b/self/history.md index 3befd01..326e4e6 100644 --- a/self/history.md +++ b/self/history.md @@ -10,6 +10,11 @@ Self is often cited as an influential programming language that many developers The language emerged from frustration with Smalltalk's complexity. Ungar, fresh from his award-winning Berkeley dissertation on Smalltalk performance, joined Smith at PARC to explore a radical simplification: what if object-oriented programming didn't need classes at all? +## Evidence basis + +This report relies primarily on original Self papers, doctoral theses, and the project-maintained bibliography archive at `bibliography.selflanguage.org`. +Later ecosystem-impact claims (for example, influence on specific VMs or languages) are based on a mix of primary statements and secondary engineering retrospectives, and should be read as historically grounded but interpretive. + ## From PARC to Stanford to Sun: a research odyssey Self's journey through three institutions shaped both the language and the engineers who would later transform the industry. The **design phase at Xerox PARC (1985-1986)** established the conceptual foundations, with Smith bringing insights from his Alternate Reality Kit prototype system and Ungar contributing deep expertise in dynamic language implementation. @@ -22,7 +27,7 @@ The **Sun Microsystems era (1991-1995)** brought additional talent, including ** Self's core insight was that classes are not strictly necessary for object-oriented programming. Objects inherit directly from other objects through **prototype delegation**—when a message is sent, the system searches the receiver for a matching slot, then recursively searches parent objects. Creating new objects requires only **cloning** existing ones, not instantiating from abstract class descriptions. -This simplicity created severe performance challenges that drove groundbreaking innovations. A key one was **maps** (now called "hidden classes" in V8): an implementation-level structure that transparently groups objects with identical slot layouts. Since objects cloned from the same prototype typically share structure, maps enabled class-like optimization without language-level classes. V8's documentation explicitly acknowledges: "This basic idea is not new—the prototype-based programming language Self used maps to do something similar." +This simplicity created severe performance challenges that drove groundbreaking innovations. A key one was **maps** (now called "hidden classes" in V8): an implementation-level structure that transparently groups objects with identical slot layouts. Since objects cloned from the same prototype typically share structure, maps enabled class-like optimization without language-level classes. V8 implementation documents describe hidden classes in ways that closely mirror these Self-era techniques. **Polymorphic inline caches (PICs)**, introduced by Hölzle, Chambers, and Ungar in 1991, solved the problem of call sites that encounter multiple receiver types. Rather than falling back to slow dictionary lookups, PICs generate stub routines that test receiver types and branch directly to cached methods. Published results showed clear median speedups on representative workloads, and the technique became standard in modern JavaScript engines. @@ -38,7 +43,7 @@ The project did not disappear. Community members released Version 4.4 in 2010 wi ## Legacy: powering modern runtimes invisibly -Self's influence flows through two channels: language design and virtual machine technology. **Brendan Eich** explicitly adopted Self's prototype model when creating JavaScript in 1995, later writing: "I'm not proud, but I'm happy that I chose Scheme-ish first-class functions and Self-ish prototypes as the main ingredients." JavaScript's prototype-based inheritance model traces directly to Self. +Self's influence flows through two channels: language design and virtual machine technology. **Brendan Eich** has cited Self and Scheme as key influences when creating JavaScript in 1995. JavaScript's prototype-based inheritance model traces directly to Self. **NewtonScript** (1993) adapted Self for Apple's Newton PDA, demonstrating that prototype-based programming could work on resource-constrained devices. **Lua**'s metatable mechanism enables Self-style delegation. **Io**, **Slate**, and numerous research languages carried forward the prototype paradigm. diff --git a/self/timeline.md b/self/timeline.md index 109bd16..c831f73 100644 --- a/self/timeline.md +++ b/self/timeline.md @@ -6,6 +6,11 @@ created: 2026-01-23 _January 23, 2026_ +## Evidence basis + +Dates are compiled from primary papers, thesis records, project-maintained Self archives, and release artifacts. +Some lineage milestones (especially cross-project influence claims) are synthesis from multiple sources rather than single canonical records. + ## Predecessors **1972** — Smalltalk created at Xerox PARC by Alan Kay, Dan Ingalls, and Adele Goldstein @@ -97,3 +102,10 @@ _January 23, 2026_ **August 2024** — Self 2024.1 released with FreeBSD and NetBSD support **Present** — Self maintained on GitHub; V8 and HotSpot continue to use optimization techniques shaped by Self research across a vast global software footprint + +## Key references + +- Self bibliography and primary papers: https://bibliography.selflanguage.org/ +- Self language project site: https://selflanguage.org/ +- Self source and releases: https://github.com/russellallen/self +- V8 hidden classes implementation notes: https://v8.dev/docs/hidden-classes diff --git a/terminal/macos-terminal-emulators.md b/terminal/macos-terminal-emulators.md index c000727..7eca92d 100644 --- a/terminal/macos-terminal-emulators.md +++ b/terminal/macos-terminal-emulators.md @@ -8,6 +8,20 @@ _January 27, 2026_ Terminal emulators on macOS have evolved substantially, with **GPU-accelerated rendering now standard**, graphics protocols maturing, and AI integration emerging as a differentiating feature. Ghostty's late-2024 release shifted attention in the landscape with its native Metal renderer and Zig-based performance, while established players like iTerm2 and Kitty continue advancing protocol standards. This review evaluates nine major terminals across performance, standards compliance, and integration capabilities. +## Method and source quality + +This review combines primary project sources (official docs, release notes, and repository changelogs) with independent benchmark writeups and vendor-published performance claims. +Performance numbers are directionally useful but environment-sensitive, and cross-terminal comparisons should be treated as approximate unless reproduced under identical workloads, fonts, and rendering settings. +Where claims come from vendor benchmarks or project-authored posts, they are labeled as such and should be interpreted as self-reported. + +## Methodology transparency + +- **Coverage:** Nine actively maintained macOS terminal emulators with meaningful developer adoption and publicly documented feature sets. +- **Performance inputs:** Public benchmark reports and release-note measurements, not a single controlled benchmark run by this report author. +- **Protocol matrix process:** Capability tables are derived from first-party docs and release announcements, with partial-support entries used when feature behavior is constrained. +- **UX assessment basis:** Integration and workflow claims are based on documented features plus repeat themes in practitioner discussions. +- **Comparability caveat:** Memory, latency, and throughput figures vary with fonts, rendering backends, shell workloads, and hardware generation. + ## Performance leaders differ by metric Raw throughput and input latency tell different stories. Alacritty often leads raw throughput in vtebench-style workloads, while tuned Kitty and Alacritty configurations frequently lead interactive latency measurements. Ghostty's SIMD-focused text pipeline has shown strong UTF-8 throughput in project and independent benchmarks. @@ -183,3 +197,14 @@ The macOS terminal landscape in 2026 offers distinct choices rather than margina Ghostty's emergence validates demand for native implementations prioritizing platform conventions, while Warp's commercial success demonstrates appetite for AI-integrated terminals despite open-source alternatives. The graphics protocol fragmentation—Sixel vs. Kitty Graphics vs. iTerm2—may gradually consolidate around Kitty Graphics as more terminals adopt it, though Sixel's broader legacy support ensures continued relevance. Terminal.app's macOS Tahoe updates finally address a longstanding limitation with true color support, potentially satisfying casual users who previously needed third-party alternatives. For serious development work, however, the third-party ecosystem's decade-plus advancement in features, performance, and customization remains difficult to match through incremental improvements to Apple's built-in offering. + +## Key references + +- iTerm2: https://iterm2.com/ +- Kitty docs and protocol notes: https://sw.kovidgoyal.net/kitty/ +- Ghostty docs: https://ghostty.org/docs +- Alacritty project and releases: https://github.com/alacritty/alacritty +- WezTerm docs: https://wezterm.org/ +- Warp product and docs: https://www.warp.dev/ +- Rio terminal project: https://github.com/raphamorim/rio +- Apple Terminal User Guide: https://support.apple.com/guide/terminal/welcome/mac diff --git a/terminal/tmux-history.md b/terminal/tmux-history.md index 1a84641..668ffab 100644 --- a/terminal/tmux-history.md +++ b/terminal/tmux-history.md @@ -8,6 +8,12 @@ _January 27, 2026_ **tmux, a terminal multiplexer that helped reshape command-line workflows, was created by Nicholas Marriott in 2007 as a cleaner, BSD-licensed alternative to GNU Screen.** What began as a personal project driven by frustration with Screen's unreadable codebase became one of the more influential developer tools of the 2010s. After OpenBSD founder Theo de Raadt personally audited the code and found it "high quality," tmux was imported into the OpenBSD base system on June 1, 2009, a noteworthy event that signaled production readiness. Today, with **40,000+ GitHub stars** and inclusion in most Unix-like operating systems, tmux is a widely adopted choice for terminal multiplexing. +## Method and source quality + +This history is built primarily from project-maintained artifacts (the tmux repository and changelog), OpenBSD records, and contemporaneous interviews. +Adoption indicators such as package availability and GitHub stars are directional, not fixed, and should be interpreted as approximate. +Community tutorials and plugin ecosystem references are included for ecosystem context, but they are secondary sources. + --- ## Nicholas Marriott and the creation story