Notes on Structured Programming.¶
Dijkstra, E. W. (1972). Notes on Structured Programming. Structured Programming.
Cited by¶
4 citations across 4 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Falsifiability
- Software engineering: Testing can reveal the presence of bugs but never their absence (Dijkstra's dictum); one failing case refutes "the code is correct," while any number of passing cases only corroborates it.
This sourceSource of the dictum, Sec. 3 ('On the Reliability of Mechanisms'): 'Program testing can be used to show the presence of bugs, but never to show their absence!' - one failing case refutes 'the code is correct' while passing cases only corroborate.
- Software engineering: Testing can reveal the presence of bugs but never their absence (Dijkstra's dictum); one failing case refutes "the code is correct," while any number of passing cases only corroborates it.
- Refinement
- This distributes complexity across multiple manageable cycles rather than requiring upfront omniscience, the discipline Dijkstra (1972) advocates in his Notes on Structured Programming as the foundation for managing program complexity.
This sourceIn O.-J. Dahl, E. W. Dijkstra, & C. A. R. Hoare, Structured Programming (pp. 1–82). Academic Press. Argues that intellectually manageable programs are built by hierarchical decomposition and stepwise refinement, distributing total complexity across many small, locally verifiable steps.
- This distributes complexity across multiple manageable cycles rather than requiring upfront omniscience, the discipline Dijkstra (1972) advocates in his Notes on Structured Programming as the foundation for managing program complexity.
Mechanisms¶
- Adverse Adaptation Red Team
- A passed red team shows only that the tested moves failed — it is an existence proof of a weakness, never an absence proof of safety — so "we passed the red team" hardening into a blanket security claim is the classic misuse.
This sourceT.H. Report 70-WSK-03, EWD249, 2nd ed., Technological University Eindhoven (1970). States that testing can reveal the presence of bugs but never prove their absence.
- A passed red team shows only that the tested moves failed — it is an existence proof of a weakness, never an absence proof of safety — so "we passed the red team" hardening into a blanket security claim is the classic misuse.
- Property-Based Equivalence Test
- A green run is evidence, not proof — testing shows the presence of differences, not their absence,
This sourceExplains that testing can reveal bugs but cannot prove their absence because sampling cannot exhaust the enormous input space.
- A green run is evidence, not proof — testing shows the presence of differences, not their absence,
Verification¶
This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 2 other ways.
- https://research.tue.nl/en/publications/notes-on-structured-programming-2/ ×1
- https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD249/EWD249.html ×1
Registry ID ref:d166c33e2443 · see in the full table