Real Programmers Write Machine Code

“Real programmers write machine code” is treated less like a slogan and more like a case study in what optimization looked like when hardware constraints were brutally visible. In the late 1940s through 1960s, early computers—built from vacuum tubes and drum memory—made high-level abstractions expensive. Fortran emerged as a compromise, aiming to stay close to machine code because the performance penalty of early languages could be “immense.” The transcript then pivots to a specific legend: Mel, a programmer who ported and hand-tuned programs in raw hexadecimal for drum-based machines, turning timing and memory layout into the core of programming craft.

Mel’s work begins at the Royal MCB Computer Corporation, a defunct subsidiary of a typewriter company, where drum-memory word sizes varied wildly across systems. That variability forced compilers and ports to be written for each machine configuration—no universal “write once, run anywhere.” Mel’s assignment was to rewrite a Blackjack program from an LGP 30 to an RPC 4000, which required more than translating logic. It meant repacking instructions around a new addressing scheme: each instruction carried both an operation and a second address pointing to where the next instruction would be found on the revolving drum. In modern terms, it’s described like every instruction effectively followed a built-in jump.

Mel’s advantage wasn’t just low-level coding; it was physical scheduling. He loved the RPC 4000 because he could place instructions so the drum’s read head would encounter the next instruction exactly when needed. Instead of using an optimizing assembler, he refused it, hardcoding “hot loops” first—writing the most frequently executed parts so they landed in the best drum locations. The transcript contrasts his hand-optimized approach with assembler output, claiming his versions ran faster, especially for performance-critical tasks like encryption algorithms that still often rely on hand-tuned low-level work.

A key detail is how Mel handled delays without explicit time-delay loops. Rather than inserting waits, he arranged successive instructions so each one would be available after a full drum rotation or the required latency. He even coined a term for the opposite of optimizing—“maximum time delay locations”—to describe deliberate placement that exploited the drum’s timing rather than fighting it.

The story turns ethically messy when sales wanted the Blackjack program to cheat by changing odds via a console sense switch. Mel refused at first, calling it dishonest. Under pressure, he eventually produced code that appeared to cheat—but the transcript suggests the test logic was reversed, causing the program to win every time when the switch was on. After Mel left, a later review found no straightforward “offending test,” implying the behavior was rooted in deeper control-flow and hardware-specific assumptions.

The transcript closes by broadening the “real programmer” archetype: memorizing opcodes, writing without comments, using debuggers, and treating code as an art form shaped by the machine’s realities. Mel’s drum-memory mastery—timing instruction execution to the drum’s 17-millisecond revolution—becomes the centerpiece example of why “bare metal” programming once mattered so much, and why it still fascinates.