Dennis Ritchie and the C Language

Zusammenfassung

Dennis Ritchie designed C between 1969 and 1973 at Bell Labs — not as an academic exercise, but as a practical tool for writing an operating system. The result was a language that achieved something rare in engineering: it was both close enough to the hardware to be efficient and abstract enough to be portable. C did not merely succeed; it became the mother tongue of computing, the substrate on which C++, Java, Python, and dozens of other languages were built, and the language in which virtually every operating system, database, and runtime environment in existence was written. Fifty years later, it still runs the world.

The Prehistory: BCPL and the Problem of Portability

To understand why C was created, it is necessary to understand the problem it was designed to solve — and the language it evolved from.

In the 1960s, programming languages fell into two camps. High-level languages like FORTRAN and COBOL were productive to write but generated inefficient code and were tightly coupled to specific compilers and machines. Assembly language was efficient and precise but entirely machine-specific: code written for an IBM 360 was useless on a GE-645 or a DEC PDP-7.

BCPL — Basic Combined Programming Language — was developed by Martin Richards at the University of Cambridge in 1967 as a response to this problem. BCPL was typeless: it had a single data type, the machine word, and operated directly on memory. This made it simple to compile and port across different hardware architectures. It was, in essence, a structured layer over assembly — providing functions, control structures, and a compiler while staying close to the machine.

BCPL reached Bell Labs in the late 1960s, where Ken Thompson encountered it. Thompson had already written the first version of Unix on a PDP-7 — an experiment in operating system design described more fully in The Unix Story. Working from BCPL, he created a simplified variant he called B, adapted to the PDP-7’s limited word size and memory model.

B shared BCPL’s fundamental design: it was typeless, operating on machine words, with no distinction between integers, characters, or pointers. On the PDP-7’s 18-bit word architecture, this was workable. When Bell Labs acquired a PDP-11 in 1970, the problem became clear: the PDP-11 had characters, 16-bit integers, and 32-bit integers — multiple distinct data sizes that a single-type language could not represent cleanly. B programs on the PDP-11 were slow and awkward because the language had no way to talk about bytes.

The Creation of C: 1969–1973

Dennis MacAlistair Ritchie joined Bell Labs in 1967. He had studied physics and applied mathematics at Harvard and completed a doctoral thesis on subrecursive hierarchies of functions — though, in a quirk unnoticed for decades, he never formally received the PhD, reportedly because he declined to submit the required bound copy to the Harvard library. Quiet, precise, and intellectually rigorous, he was the opposite of Thompson’s instinctive programmer’s bravura. Where Thompson worked rapidly by intuition, Ritchie’s contributions were more systematic — but no less transformative.

Ritchie began extending B to address the PDP-11’s architecture. The critical additions were types. Where B had only machine words, Ritchie introduced int, char, float, and eventually long — explicit declarations of what kind of data a variable held. From types came type checking, the ability to catch errors at compile time rather than at runtime. From types came structures (struct): the ability to group related data under a single name, a primitive form of the records that would later become objects in object-oriented languages.

The language that emerged from this work — initially called NB (New B), then simply C — retained BCPL’s and B’s most distinctive feature: pointers, direct references to memory addresses. A C pointer was not an abstraction; it was a literal memory address. This made C dangerous in careless hands — a misused pointer could corrupt any part of a program’s memory — but it also gave the language extraordinary power. A C programmer could manipulate memory with the same precision as an assembly programmer, but within a structured, portable framework.

By 1972, the language was usable. By 1973, Ritchie and Thompson had done something that had never been done before: they rewrote the Unix kernel in C.

What “Portable” Actually Meant

Before the C rewrite, Unix existed only on the PDP-7 and PDP-11 — specific hardware that Bell Labs happened to own. After the rewrite, Unix could in principle run on any machine for which a C compiler existed. In practice, porting required effort — different hardware had different assumptions about byte order, word size, and I/O — but the effort was measured in weeks, not months of assembly-language translation. When Unix spread to the Interdata 8/32 in 1977 as the first non-DEC port, it validated the approach entirely.

“The C Programming Language”: 1978

Between 1973 and 1978, C was used internally at Bell Labs and spread, through Unix tapes, to universities and research labs. It was documented through internal memos and Ritchie’s original language reference. There was no textbook.

In 1978, Ritchie and Brian Kernighan — a colleague at Bell Labs who had contributed significantly to Unix’s tools and documentation, and who had coined the term “Hello, World!” — published “The C Programming Language”. It was 228 pages long. Its prose was precise, spare, and technically exact. The examples were short programs that actually worked. Every sentence earned its presence.

The book became one of the most influential technical books ever published. Known universally as K&R (for Kernighan and Ritchie), it defined not just C but a style of technical writing that placed examples above explanation and trusted readers to learn by doing. It went through multiple editions as the language evolved; the second edition (1988), updated for ANSI C, remains in print and in use today.

The influence of K&R extended beyond C. It established a template — compact, example-driven, designed for experts — that shaped how programming books were written for the next two decades.

C as Infrastructure: The Language That Unix Spread

The Unix-C relationship was not coincidental; it was architectural. Unix was written in C. C was designed to write Unix. When Bell Labs licensed Unix to universities — for a nominal fee, since AT&T was legally barred from competing commercially — it shipped the C source code alongside it. An entire generation of computer science students learned systems programming in C.

When those students graduated and founded companies, built operating systems, or designed new languages, C was their default. The pattern repeated everywhere:

The Unix tools — grep, awk, sed, make — were written in C.
The BSD networking stack — the code through which TCP/IP spread to the academic world, described in The Connected World — was C.
Microsoft’s early products, including MS-DOS and the first Windows kernels, were built in C.
The Linux kernel, Linus Torvalds’ Unix-compatible system begun in 1991, was written in C — and remains so, with approximately 30 million lines of C code as of 2024.

C was not merely a language people happened to use. It was the portability layer through which computing concepts moved from one machine to another — the lingua franca that let code outlive the hardware it was first written for.

The Children of C: A Language Family Tree

No programming language has produced more influential descendants than C.

C++ (Bjarne Stroustrup, Bell Labs, 1979–1983) added object-oriented programming to C — classes, inheritance, polymorphism — without sacrificing C’s performance characteristics. It became the language of choice for large-scale systems software: browsers, game engines, financial systems, compilers. Chrome, Firefox, and the V8 JavaScript engine are all C++.

Objective-C (Brad Cox and Tom Love, 1983), adopted by NeXT and then Apple, layered Smalltalk-style messaging on top of C syntax. It was the language of macOS and iOS development for three decades, until Swift replaced it — though Objective-C remains in use in the enormous body of existing Apple code.

Java (James Gosling, Sun Microsystems, 1995) took C’s syntax — its brace structure, operators, and type declarations — and added garbage collection, a virtual machine for true cross-platform portability, and strict type safety. The intention was explicit: make Java look familiar to the millions of existing C and C++ programmers.

C# (Anders Hejlsberg, Microsoft, 2000) was designed as a response to Java, with similar C-derived syntax but deeper integration with Windows and later multiplatform capability through .NET.

Python (Guido van Rossum, 1991), though syntactically very different from C, was written in C from the beginning and uses C as its extension language. The standard CPython interpreter is C; virtually every high-performance Python library — NumPy, TensorFlow, PyTorch — is C or C++ wrapped in a Python interface.

Go (Ken Thompson, Rob Pike, Robert Griesemer, Google, 2009) was consciously designed as a “better C for the 21st century”: similar in philosophy, but with garbage collection, goroutines for concurrency, and a cleaner type system. The participation of Thompson — the original creator of B and Unix — was deliberate symbolism.

Rust (Mozilla Research, 2010; stable release 2015) addressed C’s most dangerous property — the manual memory management that made it powerful but error-prone. Rust’s ownership system achieves memory safety at compile time without a garbage collector. It is positioned as C’s successor for systems programming, and has been accepted into the Linux kernel for new driver development — the most significant institutional endorsement possible.

Why C Still Dominates After 50 Years

In 2024, C remains the most widely used language for embedded systems, operating system kernels, and any environment where memory control, predictable performance, and zero runtime overhead are requirements. This persistence is not inertia alone. The languages that have tried to replace C — Ada, D, Nim — achieved adoption in niches, not the mainstream. Only Rust appears genuinely likely to displace C in systems programming, and even Rust’s adoption timeline is measured in decades. C’s longevity reflects a deeper truth about software evolution: a tool that is “good enough” and ubiquitous resists replacement not because it is perfect but because the cost of switching includes retraining programmers, rewriting toolchains, and rebuilding decades of institutional knowledge. C will not disappear; it will be surrounded, gradually, by safer successors that solve specific problems better — exactly as C itself surrounded and replaced assembly.

Dennis Ritchie: The Quiet Revolutionary

By any objective measure, Dennis Ritchie was among the most influential programmers in history. C and Unix together defined the structure of computing for the second half of the twentieth century. Yet Ritchie spent his career in relative obscurity outside the technical community, content to work at Bell Labs, attend conferences, and write with characteristic precision.

He received the Turing Award jointly with Ken Thompson in 1983 — the first awarded for operating systems work. He remained at Bell Labs until its reorganization as Lucent Technologies, retiring in 2007. He died in October 2011, a week after Steve Jobs — an irony noted widely in the computing community, since Jobs’ empire was built substantially on software derived from Ritchie’s work.

Brian Kernighan, who co-authored K&R and contributed enormously to Unix’s tools and documentation, continued teaching at Princeton and writing books that maintained the spare, example-driven clarity of the original. He is, in many ways, the custodian of Ritchie’s style.

Dead End: BCPL and B — The Predecessors That Made C Necessary

BCPL and B did not simply become obsolete; they were superseded by their own logical extension.

BCPL was a genuine contribution — it demonstrated that a typeless language could be compiled efficiently across different hardware and was used in the development of early operating systems and compilers. But its typelessness was both its strength and its ceiling. On machines with a single natural word size, typelessness worked. On machines with multiple data sizes — the norm rather than the exception by the early 1970s — it produced inefficient or incorrect code.

B inherited BCPL’s limitation and added machine-specificity. Thompson’s B worked on the PDP-7 and was adapted for the PDP-11, but each adaptation was essentially a new dialect. The language had no mechanism to reason about different data sizes because it had no concept of data types at all.

The decisive evolutionary step that made C necessary was typed memory access. When the PDP-11 introduced byte-addressable memory — memory where the fundamental unit was an 8-bit character rather than a 16-bit or 18-bit word — a language that could not distinguish a byte from a word was fundamentally broken. Ritchie’s addition of types to C was not an academic concern about software engineering practice; it was a direct response to hardware reality.

BCPL survived as an academic curiosity and influenced language designers, but was never widely used outside its birthplace. B ran only at Bell Labs and faded as C spread. Neither had the right combination of portability and expressiveness. C had both, at exactly the right moment in hardware history.

The Danger in C’s Power

C’s direct memory access — the feature that made it efficient and expressive — is also the source of an entire category of security vulnerabilities that have afflicted software for fifty years. Buffer overflows, use-after-free errors, null pointer dereferences: all result from C’s fundamental design choice to trust the programmer with raw memory. The history of computer security is, in large part, a history of C programs doing something with memory that the programmer did not intend. This is not a failure of C’s design; it is the cost of its power. The question Rust attempts to answer is whether that cost is still worth paying.