The Evolution of Language: From Machine Code to Modern Abstraction

The Floor: Speaking in Ones and Zeros

The first programmers did not write code. They were the machine.

On early computers like the ENIAC, programming meant physically setting thousands of switches and plugging cables into patch panels. There was no language — only wiring. When the configuration changed, engineers spent days rewiring by hand. The distinction between “hardware” and “software” did not yet exist.

The first step toward abstraction was machine code: numeric instructions corresponding to specific CPU operations, entered directly as binary or hexadecimal values. A programmer adding two numbers might write 10110000 01100001 — a sequence that meant something to the processor and nothing to any other human being without a hardware manual.

Assembly language raised the floor slightly. Instead of binary sequences, programmers used short mnemonics: MOV AX, 1 instead of 10110000 00000001. An assembler program translated these mnemonics into machine code. But assembly was still entirely hardware-specific: a program written for an Intel chip was gibberish on a Motorola chip. Every machine was its own isolated dialect.

The cognitive burden was enormous. To write even a modest assembly program, a programmer had to hold the entire state of the machine — register contents, memory addresses, stack pointers — in their head simultaneously. Programs of any complexity became humanly unmanageable.

Grace Hopper and the Compiler Heresy

The idea that a machine could translate human-readable instructions into its own executable language was, to many engineers in the early 1950s, obviously impossible. Programs had to be written for machines, in the language of machines. The notion that a computer could help write its own programs was circular nonsense.

Grace Hopper disagreed. A mathematician and U.S. Navy Reserve officer who had worked on the Harvard Mark I during the war, Hopper had developed an intuition that programming’s real bottleneck was not computation speed but human time. In 1951 and 1952, working at Remington Rand, she wrote the A-0 compiler — the first program that translated symbolic mathematical notation into machine code.

Her colleagues were skeptical. “I had a running compiler,” she later recalled, “and nobody would touch it. They told me computers could only do arithmetic.” She demonstrated it anyway, repeatedly, until the skepticism eroded.

The A-0 was primitive by later standards. But its existence was a proof of concept that changed the terms of debate: if a machine could translate one formal language into machine code, it could translate any formal language. The door to high-level programming was open.

Her later work produced FLOW-MATIC (1955), the first programming language designed to use English-like words, and directly inspired COBOL (1959) — the Common Business-Oriented Language that would go on to run payroll systems, banking software, and government databases for decades. Hopper’s fuller story is told in Grace Hopper: The Queen of Code.

John Backus and the Performance Problem

Proving that a compiler could exist was one challenge. Proving that it could produce code fast enough to be worth using was another. Scientists and engineers writing numerical calculations were convinced that a compiler could never match the efficiency of hand-written assembly. Performance was their religion.

John Backus at IBM set out to prove them wrong. In 1957, after three years of development with a team of thirteen engineers, IBM released FORTRAN (Formula Translation) — the first high-level language adopted at industrial scale. FORTRAN allowed physicists and engineers to write programs like:

Y = A * X**2 + B * X + C

— a quadratic formula rendered almost as its mathematical equivalent. The compiler translated this into efficient machine code, often matching or approaching what a skilled assembly programmer would produce.

The response from the scientific community was immediate and enthusiastic. FORTRAN did not just save time — it made programs readable, which meant other people could maintain and build on them. The concept of collaborative software development became possible.

Backus later made an equally important theoretical contribution: together with Peter Naur, he developed Backus-Naur Form (BNF), a formal notation for describing the grammar of programming languages. BNF gave language designers a rigorous tool for specifying syntax and became the foundation on which compiler theory was built.

The Structured Programming Revolution

By the mid-1960s, high-level languages had solved the portability problem and largely addressed the performance problem. A new crisis emerged: complexity.

Programs had grown large enough that their control flow — the sequence of conditions, loops, and branching — had become incomprehensible. The culprit, many argued, was the GOTO statement: a direct jump to any arbitrary point in a program. GOTO allowed programmers to write code that twisted back on itself, creating what critics called “spaghetti code” — impossible to read, impossible to test, impossible to maintain.

In 1968, Dutch computer scientist Edsger Dijkstra submitted a short letter to the Communications of the ACM. Its title: “Go To Statement Considered Harmful.” In it, Dijkstra argued that unrestricted GOTO made programs logically intractable: the quality of a programmer, he claimed, should be inversely correlated to the density of GOTO statements in their code.

The letter was short and combative. The response was enormous. Some programmers were furious — GOTO was a tool they used constantly, and they resented a theoretician telling them their craft was harmful. Others recognized in Dijkstra’s argument a diagnosis of a real disease.

The alternative Dijkstra and others championed was structured programming: building programs exclusively from three control structures — sequence, selection (IF-THEN-ELSE), and iteration (WHILE, FOR). Mathematically provable, each structure had a single entry point and a single exit. A program built from only these structures could be reasoned about systematically.

Niklaus Wirth at ETH Zürich gave the structured programming movement its teaching instrument: Pascal (1970). Pascal enforced strict type discipline, required variables to be declared before use, and made structured control flow the only option. Universities adopted it throughout the 1970s as the definitive language for teaching programming methodology. A generation of computer science students learned to think about programs as structures — and carried that discipline into their subsequent careers.

C: The Middle Ground

Pascal was beautiful for teaching. It was constraining for systems work. Building an operating system in Pascal meant fighting the language every time you needed direct memory access, low-level I/O, or performance-critical bit manipulation.

Dennis Ritchie at Bell Labs solved this tension with C (1972), developed alongside Ken Thompson as the implementation language for the Unix operating system. C occupied a unique position: it provided high-level abstractions (functions, structured control flow, type declarations) while retaining direct access to memory via pointers, bitwise operations, and manual memory management.

The result was a language that could express both a payroll system and a device driver — a range no prior language had achieved. When Unix was rewritten in C in 1973 (the first operating system written primarily in a high-level language), it became portable: the same Unix could run on different hardware simply by recompiling the C source. The operating system and the language spread together, each validating the other.

Ritchie and Thompson’s manual, The C Programming Language (1978, with Brian Kernighan), became one of the most influential technical books ever written — concise, precise, and sufficient. C remains one of the most widely used programming languages in the world, still the language of choice for operating system kernels, embedded systems, and performance-critical infrastructure.

Objects: Modeling the World

C was powerful. It was not, its critics argued, organized. Large C programs tended to scatter related data and functions across files with no enforced structure connecting them. As software systems grew to millions of lines, a new organizational principle was needed.

The conceptual foundation had been laid in Norway, a decade before C, by Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Centre. Designing a simulation language called Simula (1967), they introduced two revolutionary concepts: the object (a bundle of data and the functions that operate on it, treated as a single entity) and the class (a template from which objects are created).

Simula was built for modeling real-world systems — ships in a harbor, customers in a queue — and its design reflected that intent: the language encouraged programmers to think in terms of things that had properties and behaviors, rather than in terms of procedures that transformed data.

Alan Kay at Xerox PARC took these ideas and radicalized them in Smalltalk (1972): an environment in which everything was an object, objects communicated only by sending messages to each other, and the entire system — including its own development tools — was written in the language. Kay’s vision was philosophical as much as technical: he wanted a programming system that would reshape how people thought, as literacy had reshaped thought.

The commercial mainstream arrived with C++ (1985), designed by Bjarne Stroustrup at Bell Labs. Stroustrup took C — with all its performance and low-level capabilities — and grafted Simula’s object-oriented concepts onto it. C++ became the dominant language of the software industry through the 1990s: powerful, efficient, and notoriously complex.

James Gosling and his team at Sun Microsystems built Java (1995) in deliberate reaction to C++’s complexity. Java simplified the object model, eliminated manual memory management (using garbage collection), and made portability its primary promise: “Write Once, Run Anywhere.” A Java program ran on any machine that had a Java Virtual Machine, regardless of operating system or hardware. Java became the language of the web’s server side, enterprise software, and — through Android — mobile computing.

The Scripting Age

The languages of the 1970s and 80s were built for professional programmers solving problems at industrial scale. The 1990s produced a different kind of demand: millions of people who needed to automate things, connect systems, and write small programs quickly — without the ceremony of declaring types, compiling, and linking.

Perl (1987, Larry Wall) was the first widely used scripting language, designed originally for text processing and system administration. It was famously pragmatic and famously cryptic: “there’s more than one way to do it” was its motto, and its programs sometimes resembled encrypted transmissions.

Python (1991, Guido van Rossum) took the opposite philosophy. Where Perl prized flexibility, Python prized readability: significant whitespace enforced indentation as structure, and the language’s design philosophy — summarized in “The Zen of Python” — valued clarity over cleverness. Python spread first among scientists and educators, then into web development, and eventually into machine learning, where its readable syntax and vast library ecosystem made it the default language for AI research.

JavaScript (1995, Brendan Eich, in ten days) was designed for a specific and modest purpose: adding interactivity to web pages. It grew, improbably, into one of the most widely deployed programming languages in history — running in every browser on earth, and increasingly on servers via Node.js. Its rapid creation showed in its early design: JavaScript accumulated inconsistencies and surprising behaviors that its users have been working around ever since.

Dead End: Languages That Failed or Were Abandoned

For every language that achieved widespread adoption, dozens were designed, deployed, and eventually abandoned. Several failures are instructive:

PL/I (IBM, 1964) was the attempt to build one language to replace all others — combining the scientific computing strengths of FORTRAN with the business capabilities of COBOL and the systems features of assembly. It succeeded at being comprehensive and failed at being usable: the language specification ran to hundreds of pages, compilers were enormous, and programmers found it almost impossible to hold the full language in their heads. PL/I is the purest example of the “second-system effect” — the tendency of ambitious follow-up designs to collapse under their own weight.

Ada (1983, DoD) represents a different failure mode: language by committee mandate. The U.S. Department of Defense, frustrated by the proliferation of incompatible languages across its contractors, commissioned a new language designed by competition. The winner, Ada, was technically sophisticated — strong typing, built-in concurrency, formal package specifications. The DoD mandated its use for all military software. Contractors complied on paper and continued writing in C whenever possible. Ada found a niche in safety-critical aviation and defense systems, where its formal rigor was genuinely valuable, but its attempt to become a universal language failed entirely.

COBOL’s Half-Life. COBOL is not quite dead, which is its own kind of failure. Written in 1959, optimized for batch processing of business records, COBOL now runs an estimated $3 trillion in daily financial transactions — ATM withdrawals, bank transfers, insurance claims. Generations of programmers who knew it have retired. Attempts to replace COBOL systems have repeatedly failed or stalled: the systems are too large, too interconnected, and too poorly documented to safely rewrite. COBOL is computing’s legacy trap: a language kept alive not by merit but by the prohibitive cost of escape.

The Present: Safety and the Limits of C

The dominance of C and C++ through the 1990s and 2000s produced a silent, continuous catastrophe: the vast majority of serious security vulnerabilities in software — buffer overflows, use-after-free errors, null pointer dereferences — stem from manual memory management in C-family languages. Billions of lines of infrastructure code contain latent bugs that attackers exploit systematically.

The response is the newest chapter in the language evolution story. Rust (released by Mozilla in 2015, led primarily by Graydon Hoare) attacks memory safety at the language level. Its ownership system — a set of compile-time rules that track which part of a program holds a reference to which data — makes entire classes of memory errors impossible by construction, without requiring garbage collection. Rust aims to occupy C’s niche (systems programming, performance-critical code) while eliminating C’s dominant failure mode.

TypeScript (Microsoft, 2012) applied a similar logic to JavaScript: adding a static type system on top of a dynamically typed language to catch errors at compile time that would otherwise surface as runtime bugs in production.

Both represent the same thesis that Dijkstra argued in 1968: that the right constraints, enforced by the language itself, make programs more reliable — not despite reducing programmer freedom, but because of it.

The arc from binary switches to Rust spans eighty years and reflects a single continuous project: making the gap between human thought and machine execution as small as possible, while keeping the machine fast enough to be worth talking to.

📚 Sources

• Backus, John: “The History of FORTRAN I, II, and III” — ACM SIGPLAN Notices, Vol. 13, No. 8 (1978)
• Dijkstra, Edsger W.: “Go To Statement Considered Harmful” — Communications of the ACM, Vol. 11, No. 3 (1968)
• Kernighan, Brian W. & Ritchie, Dennis M.: The C Programming Language (1978), Prentice Hall
• Stroustrup, Bjarne: The Design and Evolution of C++ (1994), Addison-Wesley
• Wexelblat, Richard L. (ed.): History of Programming Languages (1981), Academic Press — first-hand accounts from language designers including Backus, Hopper, and others
• Nygaard, Kristen: “The Development of the Simula Languages” — ACM SIGPLAN Notices, Vol. 13, No. 8 (1978)
• Van Rossum, Guido: “A Brief Timeline of Python” — personal blog (2009)