Modern programmers are trained to flinch at repetition. If two blocks resemble each other, extract a function. If five fields follow the same pattern, create a loop. If ten states differ by one value, represent them as data. “Don't repeat yourself” is sensible advice when the abstraction is clearer than the copies.

Then an old listing appears: hundreds or thousands of numbered statements, nearly identical branches, explicit assignments that seem to do nothing, and whole screens devoted to one small change. It is tempting to conclude that people simply did not know better. That verdict forgets the computer surrounding the code.

Programming practice is shaped by the cost of editing, storage, compilation, debugging and failure. When those costs change, good style changes with them. A structure that looks wasteful on a searchable laptop can be practical in a printed binder beside a machine that runs an overnight production schedule.

A program could be a physical object.

For much of commercial computing, source code was not primarily a fluid document on a full-screen editor. It could be a deck of punched cards, with one statement represented by one card. A conventional card provided eighty columns. Drop the deck and sequence markings mattered. Change a statement and an operator might replace a physical card. Submit the deck and the programmer waited for a compile listing or error report.

This environment favored visible landmarks. Labels and line numbers were addresses that could be written on a defect report, found in a listing, or used as branch targets. Numbering in increments left space for later insertions. A block beginning at 800 and another at 900 advertised its rough location before anyone interpreted its logic.

The first Dartmouth BASIC manual, published in 1964, defined an instruction as an instruction number, an operation and an operand. Its examples used line numbers for both sequence and transfer of control. DATA statements stored values inside the program; READ consumed them. These were not decorative conventions borrowed by nostalgic hobbyists. They were part of the language model presented to students.

Repetition made state visible.

Consider a controller for a tape library, manufacturing cell or broadcast automation rack. State two and state three may differ only in which slot is empty. A modern implementation could store the states in a table and run one generic transition function. That is compact and usually easier to extend.

An older implementation might spell out each transition. One block handles slot three; the next handles slot four. The blocks are almost identical. The value that changes is surrounded by repeated assignments, repeated comments and a repeated status message.

Why tolerate it? Because an operator investigating state three can open the listing at the state-three block and see everything the transition claims to do. A technician can compare two adjacent blocks line by line. A change ticket can say “replace card 940.” A trace can print the current line number. The duplicated context costs paper and storage, but it reduces indirection.

That trade is especially understandable when the controlled process is physical. A robotic arm, tape carousel or broadcast chain does not care that the program is elegant. It cares that a command arrives in the right order and that an interrupted movement can be recovered. Explicit blocks can make sequencing and recovery procedures easier to match with a service manual.

This does not mean duplicated code is inherently reliable. Copies drift. A correction applied to four blocks can miss the fifth. Repetition can conceal inconsistency and make testing expensive. The point is narrower: duplication sometimes purchased local readability and operational traceability in environments where navigation and instrumentation were poor.

Abstraction was not free.

Every abstraction asks the reader to leave the current location. A subroutine call requires finding the subroutine and understanding its inputs, outputs and side effects. A table-driven system requires understanding both the interpreter and the data. On a modern workstation, “go to definition,” search, version control and automated tests make that movement cheap. In a binder, it means turning pages and keeping several distant sections in working memory.

Machines also imposed limits. Memory could be scarce. Function-call mechanisms could be awkward or dialect-specific. Compilers and interpreters varied. A language marketed under one name could have vendor extensions, missing facilities or system-specific input/output. Code intended for one installation might privilege the constructs its local compiler handled predictably.

Source listings served several audiences beyond the author. Operators used them to match messages to locations. Auditors used them to follow business rules. Vendor technicians used them to diagnose interactions with equipment. Students learned from them. The code therefore doubled as documentation, and repetition could behave like repeated headings in a procedural manual.

Line numbers were interfaces.

Line numbers are now associated with beginner languages and spaghetti control flow, but they solved several concrete problems. They established order, named branch destinations and gave people a common vocabulary for discussing the program. A printed error that identified line 1040 pointed to an exact statement. A patch could be communicated as a replacement range.

The costs are equally real. A program organized around jumps can scatter meaning across distant locations. Insertions consume numbering gaps. Large renumbering operations complicate comparison between versions. Structured programming, symbolic labels and better editors reduced the need to make numeric addresses carry so much meaning.

Yet the older convention survives in unexpected places. Logs still include source locations. Incident tickets cite file and line. Database migrations and network standards use stable numeric identifiers. Modern developers did not abolish addresses; they moved them into tooling.

Lotus Notes exposed a related style.

Later business platforms produced their own forms of explicit repetition. Lotus Notes and Domino applications combined documents, fields, forms, views and formula expressions. Formula language provided concise functions such as @If, field assignment and list operations, but real applications could still contain repeated field-by-field logic.

That repetition often reflected the data model. A form exposed named fields that mattered to users and workflows. Treating Rack_1, Rack_2 and Rack_3 explicitly could make each result inspectable in the document. A trace field could append separators and location markers after every evaluation. The formula became both computation and a readable diagnostic record.

A contemporary engineer might generate those fields, map a collection or emit structured telemetry. Those are stronger options when the platform supports them cleanly. But the old formula reveals the same priority: leave evidence in the object an administrator already knows how to inspect.

Do not romanticize the mess.

Historical context explains repetition; it does not sanctify it. Old systems contain accidental complexity, copied defects and code that was poor even by the standards of its time. Programmers argued about structure, modularity and maintainability long before personal computers. The existence of constraints does not prove every listing represents the best possible response.

Nor should a modern team imitate a 1960s listing for atmosphere. If a state table makes the differences obvious and tests guarantee every transition, use the table. If a loop turns five inspectable operations into one opaque tangle of conditionals, keep some explicitness. The correct unit is not minimum line count. It is minimum total confusion for the people who must change and operate the system.

What the example gets right

A teaching example that uses BASIC-style line numbers, DATA, READ, FOR/NEXT and repeated state blocks is not claiming to reproduce a particular vendor controller. It is illustrating a family resemblance: numbered program locations, embedded state data, repeated transitions and printed trace messages.

That distinction matters. An image from a film cannot establish the exact source language or the exact automation platform. A prop listing may be authentic, borrowed, simulated or assembled from several materials. The useful claim is not “this is definitively the production code.” It is that the visual grammar—large listing, stable numeric locations, documentation beside a terminal—matches real methods by which complex systems were understood.

Cyberdelia assessment

The lesson of old repetitive code is not that the past was better. It is that software has always been written for an environment larger than the language. Paper, card readers, compiler turnaround, memory limits, service procedures and human handoffs all left fingerprints in program structure.

When modern engineers encounter a repeated block in a legacy system, the first question should not be “Why were they so bad at this?” Ask what capability the repetition supplies. Does it isolate a device? Anchor a printed procedure? Preserve a patch boundary? Support a trace? Encode a business exception? Once that function is understood, it can be replaced deliberately rather than erased accidentally.

The repetition may be debt. It may also be the index.

Method and limitations

Cyberdelia compared the 1964 Dartmouth BASIC manual, IBM historical material on punched-card programming, and current HCL Domino formula-language documentation. The article describes common pressures, not a universal style. Hardware, operating systems, languages and local practices varied widely. No claim is made that the illustrative BASIC or formula-language samples are executable on a specific broadcast automation controller.

Sources and further reading

Corrections: Cyberdelia preserves material corrections and updates through the site's correction process.