The reading room · Digna Legi
Programming as Theory Building
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. The supplied text contains sampling gaps and OCR artifacts. The visible case and reasoning support the central distinction, but do not establish the universal rejection of procedural programming methods or reveal the full treatment of objections.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
For Naur, software's capacity to evolve depends on programmers' living understanding of its design, which code and documentation cannot fully convey.
AI brief · Checked against source text
The main idea
Peter Naur argues that programming primarily builds a theory in programmers' minds: an understanding of how a program serves real activities, why its design makes sense, and how it can accommodate change. Drawing on Gilbert Ryle, he treats this as the ability to act intelligently and explain that action; written artifacts support this understanding but cannot, he argues, fully contain or transmit it.
Some background helpful. Basic familiarity with software design, maintenance and the role of program documentation.
Go a little deeper
Correct behavior can conceal structural decay
A requested change can have several implementations that produce the same outward behavior. Naur distinguishes changes that develop the existing design from patches that bypass it. Their difference depends on understanding why the structure exists and what alternatives it excludes. Functional correctness therefore leaves an important question unanswered: does the change preserve the reasoning that makes future changes intelligible?
Continuity requires guided participation
Naur calls a program dead when the team holding its theory dissolves, even if the software still produces useful results. Successors need opportunities to investigate unexpected behavior and make changes alongside experienced programmers. His comparison with learning an instrument matters: familiarity with written material differs from acquiring judgment through supervised practice. Reconstructing understanding afterward may yield a different theory that fits the inherited code imperfectly.
Methods can educate without governing thought
Naur separates learning techniques from obeying a prescribed sequence. Model solutions, verification techniques and principles for organizing interacting parts can strengthen a programmer's repertoire. What he rejects is the claim that fixed procedural rules can determine which technique fits a particular problem and when to apply it. He reads Polya's problem-solving suggestions as prompts for thought rather than a mandatory workflow.
A case from the article
A compiler handoff that needed its designers
A team extending an existing compiler received annotated code, extensive design documentation and personal advice. Despite that preparation, it proposed additions that bypassed capabilities already present and documented. The original designers immediately identified simpler solutions within the existing structure. The case illustrates a specific transfer failure: being given an explanation did not ensure that successors could recognize when its design ideas applied.
How the case is made
Naur combines two firsthand or directly reported software cases with Ryle's account of practical understanding and explanatory knowledge.
Where the idea has limits
Naur's rejection of prescribed methods does not reject documentation, verification or structured design; he treats these as resources whose appropriate use requires judgment.
A question to take away · from Digna Legi
What would demonstrate that someone understands a system well enough to change it, beyond being able to describe its current behavior?
What the original adds
The original also examines the speculative cost of built-in flexibility and argues for programmers' permanent professional status, while leaving open how far theory formation can be taught.
Why return to this
Read this before treating a handover as a transfer of files. Naur distinguishes the program text from the understanding that lets its authors explain design choices, connect them to the world and respond coherently when requirements change.
Engineering teams maintaining software and transferring responsibility for it.
Naur develops a theory of programming from cases and philosophical argument. Documentation remains useful in his account; it cannot by itself guarantee that a successor has acquired the original team's understanding.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.