proomt

Search

Search posts, papers, and topics

Hall of Fame

Hall of FamePeter Naur198530 min readintermediate

Programming as Theory Building

Read on rauzy.nameHN 4·1 comments

Summary

This classic essay argues that a program is fundamentally a 'theory' – a shared mental construct in the minds of its developers, not merely its source code. The code is a lossy representation, and losing the people who hold this theory means losing the program's true essence and design rationale.

  • A program's source code is an incomplete and lossy representation of the underlying 'theory' held by its developers.
  • The 'theory' encompasses the deep understanding, explanations, and justifications for the program's design and behavior.
  • Losing the original developers means losing this crucial 'theory,' making effective maintenance and evolution extremely difficult.
  • Documentation, however thorough, cannot fully convey the nuanced, implicit knowledge of the program's theory.

This foundational essay is essential for any software engineer or manager to understand the human-centric nature of software and the challenges of knowledge transfer and long-term maintenance.

9/10
architecturesoftware engineeringmaintenanceknowledge managementprogramming philosophyteam dynamics

Related reading

  1. No Silver Bullet: Essence and Accidents of Software Engineering

    Brooks argues that software development’s fundamental difficulty lies in essential complexity—conceptual design, conformity, changeability, and invisibility—rather than accidental implementation issues. Consequently, no single technology or management trick will yield an order‑of‑magnitude productivity boost; progress must come from disciplined, incremental improvements.

    Hall of Fameunc.edu34 minpaperHN11731

  2. Growing a Language

    Guy Steele argues that programming languages should be designed to grow, starting from a small core and providing mechanisms for users to extend them. He illustrates this with historical examples and shows why a static, fully‑specified language is impractical.

    Hall of Famevirginia.edu43 minHN3

  3. Learnable Programming

    Bret Victor argues that teaching programming requires environments that make code vocabulary, state, and execution flow visible and understandable, not just live‑coding output. He proposes design principles—transparent labeling, contextual explanations, and controllable visualizations—to help learners think rather than memorize.

    Hall of Fameworrydream.com41 minHN1080183

  4. Article: Your Next DSL Author Is a Language Model

    Typed Domain Grounding (TDG) embeds a DSL inside a mainstream language the LLM already knows (e.g., Kotlin) and uses the host compiler as an oracle. The author describes five building blocks—embedding, choosing a host language with high training‑data frequency, compiler‑driven type safety, a generate‑compile‑repair loop, and an on‑demand teaching tool—and shows measured results from kUML, a Kotli…

    InfoQinfoq.com18 min

  5. The Humble Programmer

    Dijkstra recounts the early struggle for programming to be recognized as a profession, noting how increased hardware power paradoxically led to a "software crisis" by enabling more complex ambitions. He argues that machine designs often exacerbate this, emphasizing that the core challenge is managing complexity, not just hardware optimization.

    Hall of Fameutexas.edu30 minHN13535

  6. Markdown in /src

    The essay argues that Markdown should be treated as source code and checked into a /src/md directory alongside the implementation it describes. Keeping intent in diffable, reviewable Markdown lets teams generate code and tests from it while preserving locality for both humans and AI agents.

    Lobstershtmx.org6 minHN10150lobste.rs12