The short answer
Literate programming arranges explanation for a reader while keeping machine-readable program text in the same source. WEB made that relationship concrete through two processing routes with different jobs.
Original workflow aid
Match the tool to its output
The shared source connects the routes; each processor has a different responsibility.
| Country | Input and output | Next responsibility |
|---|---|---|
| WEAVE | WEB source → TeX input. | TeX composes the readable document. |
| TANGLE | WEB source → Pascal source. | A Pascal compiler produces executable code. |
| TeX | Typesetting instructions → composed document. | It does not execute the application’s Pascal algorithm. |
| CTANGLE / CWEAVE | Later CWEB counterparts for code and documentation. | Do not attribute Levy’s adaptation to Knuth alone. |
Chronology
A timeline of the turning points
Manuscript received
The accessible author manuscript records this receipt month.
Journal publication
Literate Programming appeared in The Computer Journal.
Adapted to C
Silvio Levy began the C adaptation, subsequently developed with Knuth.
Identify the paper and the kind of claim it makes
Knuth’s Literate Programming appeared in The Computer Journal 27(2), pages 97–111, in 1984. The accessible author manuscript records receipt in September 1983. It proposes organising programs for human understanding and illustrates WEB with a program that prints prime numbers, adapted from Dijkstra’s earlier example. It is a design argument supported by the author’s experience and examples. A reader should not turn its enthusiasm into a controlled experimental finding that every developer or project must benefit equally.
One source travels through two different processors
In the original WEB system, the source combines TeX documentation material and Pascal program material. WEAVE produces a TeX input file, which TeX typesets as a readable document with program information and cross-references. TANGLE assembles Pascal source, which still needs a Pascal compiler before it can execute. TeX therefore does not execute the Pascal algorithm, and TANGLE does not typeset its explanation. The manual treats the WEB file as the definitive source from which those derived files are produced. These roles describe the historical pipeline; present-day toolchains may differ.
Sources for this section: [2]
Reading order need not be compiler order
A named program part can be explained where its purpose becomes clear, then expanded into its required place in the generated program. This supports a narrative that introduces ideas before their detailed implementation. Names and cross-references connect the parts. That design is more specific than adding long comments around code that remains in the same fixed order. It also does not prove correctness: an explanation can still contain a mistaken claim, and mechanically assembling the associated program does not validate the claim.
Original exercise: read the contract before the loop
Here is a deliberately small reading plan, written as pseudocode rather than valid WEB or Pascal. The contract is: given a finite list of exact integers, report how many are strictly greater than zero. The overview is: initialise count to 0; visit each entry; report count. The part named Visit each entry means: for each value in the list, if value > 0 then increase count by 1. The explanation says that after each visit, count equals the number of positive values visited so far. The list itself is not changed.
Three questions test whether the explanation earns its place
Trace the plan on [-2, 0, 3, 3]. What is reported? What should be reported for an empty list? Finally, suppose the condition in the program part changes to value >= 0 while the contract still says strictly greater than zero. Identify the inconsistency and an input that exposes it. These questions require no WEB installation. They ask a reader to connect the overview, the named part and the meaning of the count, which is the point of this new exercise. It is not an excerpt from Knuth’s prime-number program.
Suggested answer and a useful limitation
The trace reports 2 because the two occurrences of 3 both count. The empty list reports 0, since initialisation happens even when no entry is visited. After changing the comparison, the program counts zeros as well as positive values, contradicting the unchanged contract. The one-element list [0] exposes the discrepancy: the new code reports 1 where the contract requires 0. A common source can keep the printed code connected to the assembled code; it cannot by itself keep the author’s prose true. Clear contracts, examples, review and testing still have work to do. These counts are deductions from the stated pseudocode, not measured software-performance results.
Sources for this section: [2]
CWEB is a later collaboration
Knuth’s account dates Silvio Levy’s adaptation of WEB to C to 1987 and credits both men with subsequent revisions. CWEB retains a comparable distinction: CTANGLE produces compilable program text and CWEAVE produces typesetting input. Its existence helps separate the general literate-programming idea from the original choice of Pascal. The author’s claim that competitors using the tool will overtake others is advocacy, not evidence that this guide treats as an established productivity comparison. A useful exercise can borrow the concern for explanation without making that commercial prediction.
Sources for this section: [4]
Read the caveats as part of the proposal
The 1984 paper acknowledges influences and warns that Knuth’s own experience does not establish everyone else’s. Working across WEB, TeX and Pascal also creates several possible sources of error. Those qualifications belong with the proposed benefits. The historical question is how the system connects explanation and executable construction; the practical question is whether a reader can follow and check that connection in a particular program. This guide neither reproduces all of WEB nor independently verifies the full prime-printing implementation.
Sources for this section: [1]
Connected biographies
People and research
1938–present
Donald Knuth
Computer scientist, mathematician and authorDonald Knuth connected mathematical analysis with the craft of writing programs. His books organised algorithms for study, while TeX, METAFONT and WEB joined practical software development with typography and explanation.Read biographyQuick answers
Common questions
- Is WEB the World Wide Web?
- No. The name here refers to Knuth’s programming and documentation system, described in the early 1980s.
- Does TANGLE produce an executable directly?
- It produces Pascal source in the original workflow. A separate Pascal compiler produces executable code.
- Does one source guarantee that the explanation is correct?
- No. It links the generated program text and document, but prose claims and algorithmic behaviour still need checking.
Primary and institutional sources
How this history was checked
Original records and institutional histories support the historical account. Worked exercises are newly written teaching examples, not historical programs, measurements or experimental results. This article was reviewed on 27 October 2026.
- Donald E. Knuth; Tufts University teaching archiveLiterate Programming, author manuscript of 1984 Computer Journal paper
- Donald E. Knuth; CTANThe WEB System of Structured Documentation: user manual
- Stanford UniversityBibliographic record: Computer Journal27(2),97–111(1984)
- Donald E. Knuth, Stanford UniversityKnuth and Levy: CWEB, adaptation date and tool roles