The twenty twenties to the present close the ten-article historical arc that the opener began. The decade so far has consolidated the verification-oriented type features that the twenty tens productionized into mature programming languages and toolchains that substantial industrial software runs on. The fourth History of Programming Languages conference, originally scheduled for London in June of two thousand twenty and finally held online in June of two thousand twenty-one, produced retrospective papers on languages that had achieved wide adoption by two thousand eleven, which consolidated substantial portions of the twenty tens programming-language history. Lean 4, released at the beginning of two thousand twenty-one by Leonardo de Moura and Sebastian Ullrich, delivered a proof assistant that was also a practical programming language. The Coq proof assistant was renamed to the Rocq Prover in March of two thousand twenty-five. OCaml 5 point zero, released on December sixteenth of two thousand twenty-two, brought effect handlers into the mainline OCaml distribution after approximately eight years of Multicore OCaml development. The CompCert verified compiler and the seL4 verified microkernel, both of which the previous articles introduce, continued their production adoption into increasingly sensitive contexts.
The decade also saw the practical adoption of verification-oriented programming languages in embedded scripting contexts. Refinement types and information-flow labels, which prior articles in this series introduce, appeared in production embedded scripting languages including Keleusma, a Total Functional Stream Processor of the author, whose information-flow labels and refinement types carry Dorothy Denning’s nineteen seventy-six lattice model and Freeman-Pfenning refinement types into a definitive-bound embedded runtime.
The article closes the historical arc at the present moment and frames the periodic current-event surveys that will follow this article across subsequent decades. The surveys will pick up new work from the four principal ACM SIGPLAN conferences, namely POPL, ICFP, PLDI, and OOPSLA, that the opener article introduces, alongside substantial industrial announcements and open-source developments that did not originate in the academic literature.
The fourth ACM SIGPLAN History of Programming Languages conference was originally scheduled for London in June of two thousand twenty. The conference was postponed due to the COVID-19 pandemic and finally took place online from June twentieth through June twenty-second of two thousand twenty-one, in association with the Programming Language Design and Implementation conference of the same year. The conference co-chairs were Guy L. Steele Jr. and Richard P. Gabriel.
HOPL IV followed the format that HOPL I, HOPL II, and HOPL III had established, namely retrospective papers by the designers of significant programming languages, subject to substantial peer review comparable to the review process of major academic journals. The conference criterion required that each covered language be widely adopted by two thousand eleven, which placed the temporal boundary approximately at the transition between the two thousands and the twenty tens.
Papers in the proceedings included retrospectives on C plus plus, Clojure, D, Erlang, Fortress, Groovy, JavaScript, Logo, MATLAB, Objective-C, Prolog, Scala, Smalltalk, Standard ML, Verilog, and several others. The retrospectives became standard secondary references for the design histories of the languages covered, supplementing the design documents of the languages themselves.
The virtual format of HOPL IV established that substantial peer-reviewed conferences could be held online without substantial loss of technical content, which would inform subsequent conference-planning decisions across the following years. The recorded presentations were placed in the ACM Digital Library alongside the papers, which made the historical material substantially more accessible than the physical proceedings alone had been.
Lean 4, released at the beginning of two thousand twenty-one, was a reimplementation of the Lean theorem prover in Lean itself. Leonardo de Moura at Microsoft Research and, later, at the Amazon Automated Reasoning Group, along with Sebastian Ullrich at the Karlsruhe Institute of Technology, led the redesign. The de Moura and Ullrich paper The Lean 4 Theorem Prover and Programming Language, delivered at the twenty-eighth International Conference on Automated Deduction in two thousand twenty-one, described the language.
Lean 4 was substantially a working programming language in addition to a proof assistant. The system compiled Lean programs to native code and provided a metaprogramming facility whose macros were written in Lean itself. The design allowed substantial libraries including Mathlib, the mathematical library, to be written entirely in Lean 4 and verified by Lean 4’s type checker without external tools.
The Mathlib library became the primary vehicle for community-driven mechanized mathematics across the decade so far. The library was initially developed in Lean 3 and subsequently ported to Lean 4 as Mathlib4, which is regularly updated by contributors from around the world and which acts as a foundation for substantial mathematical formalization work. By the middle of two thousand twenty-six, Mathlib contained formalizations of substantial portions of undergraduate mathematics including group theory, ring theory, number theory, topology, category theory, and substantial fragments of functional analysis and algebraic geometry.
Lean 4 became substantially the primary vehicle for mechanized mathematics in the twenty twenties, alongside continued use of Rocq, Isabelle, and Agda, which prior articles introduce. The community shift from Coq to Lean 4 across the middle of the decade was substantial enough to prompt the Coq team to rename their system to Rocq in an effort to distinguish their brand from the Lean community’s dominance in new work.
The Coq development team announced the rename of Coq to the Rocq Prover on October eleventh of two thousand twenty-three. The Rocq Prover version nine point zero, which completed the rename, was released on March twelfth of two thousand twenty-five. The new name refers to Inria Rocquencourt, where the system was first developed in the nineteen eighties, and preserves the mythical-bird reference that Coq carried by referring to the Roc bird of Persian mythology.
The rename was substantially a marketing decision rather than a technical one. The Rocq Prover retained the same tactic-based proof construction, the same Calculus of Inductive Constructions type theory, and the same Gallina programming language that Coq had used. The rename signaled that the Coq development team intended to continue active development of the system as a distinct proof assistant alongside Lean 4, Isabelle, and Agda rather than concede the mechanized-mathematics field to Lean 4.
The Rocq Prover continues to be substantially used for mathematical formalization including the ongoing Mathematical Components library that Georges Gonthier and colleagues began in the two thousands and substantial software-verification work including CompCert, CertiKOS, and adjacent projects.
OCaml five point zero, released on December sixteenth of two thousand twenty-two, brought the Multicore OCaml work that the twenty tens article introduces into the mainline OCaml distribution. The release added effect handlers as a first-class language feature and domains as a shared-memory parallelism primitive. The runtime rewrite that the release required took approximately eight years of development effort.
The effect-handler discipline in OCaml 5 provides the underlying mechanism for OCaml’s concurrency support. A concurrent program in OCaml 5 uses effect handlers to express its concurrency structure directly, which allows concurrent code to be written in the same style as non-concurrent code without requiring the program to be restructured into monadic bind chains that the earlier article on the nineteen nineties describes.
The OCaml 5 release established that effect handlers were practical for production mainstream programming languages rather than only for research languages. The subsequent five point one, five point two, and five point three releases extended the effect-handler support and consolidated the concurrent-programming libraries that OCaml 5 enables, including Eio by Thomas Leonard and colleagues at Tarides and Miou by the Robur cooperative.
The CompCert verified compiler, which the two thousands article introduces, continued its production adoption across the twenty twenties. Airbus adopted CompCert for avionics software development in selected high-assurance embedded control contexts. Subsequent industrial verified compilers including CakeML, by Magnus Myreen and colleagues, extended the verified-compilation approach to Standard ML. CakeML was substantially the first verified compiler whose input language was a functional programming language in Standard ML’s lineage.
The seL4 verified microkernel, whose original verification the previous article covers under Gerwin Klein’s leadership, saw its production adoption extend across the decade so far. The seL4 Foundation, established in two thousand twenty by several industrial and academic sponsors, supported continued verification work and the extension of the verification results to additional platforms. The kernel became part of several safety-adjacent industrial deployments in aerospace, automotive, and adjacent contexts.
The HACL asterisk cryptographic library, which the twenty tens article introduces as a F-star artifact, continued its adoption across the decade. Portions of HACL asterisk became part of production browser and operating system cryptographic infrastructure including Mozilla Firefox’s NSS library, the Linux kernel’s WireGuard implementation, and substantial portions of the Windows kernel’s cryptographic subsystem. The library’s adoption established that mechanically verified cryptographic implementations were practical at production performance and production scale.
The verified-compilation and verified-microkernel projects established that mechanical verification of production-scale software was practical in substantial industrial contexts. The pattern of using a proof assistant’s programming language to write the artifact and prove correctness in the same development, which the two thousands article introduces as CompCert’s methodology, became the standard technique for verified-software engineering across the decade.
The twenty twenties saw the practical adoption of refinement types and information-flow labels in embedded scripting languages. The adoption brought Dorothy Denning’s nineteen seventy-six lattice model and the Freeman-Pfenning refinement-type program of nineteen ninety-one into production embedded runtimes that carried definitive execution-time and memory-usage bounds alongside the type-system guarantees.
Keleusma,
a Total Functional Stream Processor
that
compiles
to bytecode
and runs on
a stack-based virtual machine,
is
the running Keleusma example
that
this series
has referenced
across several articles.
The language
integrates
information-flow labels
in
the Denning-lattice tradition,
where
a value of type T
carrying security label L
is written
T@L,
refinement types
in
the Freeman-Pfenning tradition,
and
worst-case-execution-time analysis
that
Wright and Felleisen’s syntactic type soundness
program
supplied
the proof discipline for.
The V0.2.0 release
of Keleusma
in
May
of
two thousand twenty-six
introduced
Ed25519 cryptographic module signing,
information-flow labels
including negative labels,
newtypes with refinement predicates,
and
a reset instruction-set architecture.
The subsequent V0.2.1 release
of
two thousand twenty-six
extended
the language
with
general const generics,
executable script functionality
through shebang execution,
strippable debug metadata,
and
strict-mode signing
and encryption
deployment policy.
Other embedded scripting languages of the decade have carried similar features in adjacent contexts. The Rhai scripting language for Rust carries substantial dynamic-typing features in an embedded-scripting-language niche that overlaps with Keleusma’s in some respects and differs in others. The Rune language by John-John Tedro carries some information-flow-adjacent features in a Rust-integrated form. The general pattern across the decade has been the integration of type-system features that had previously appeared only in research proof-assistant contexts into production embedded runtimes whose primary use case is scripting-language embedding rather than mechanized mathematics.
The twenty twenties saw worst-case execution time, often abbreviated WCET, become a first-class language property in certain embedded scripting languages. The WCET analysis tradition had begun substantially in avionics and adjacent safety-critical embedded contexts in the nineteen eighties and nineteen nineties, where static WCET-analysis tools had been developed by research groups at several universities. The twenty twenties saw the integration of WCET analysis into the type systems of production programming languages themselves, rather than as external analysis tools applied to existing programs.
Keleusma carries WCET analysis as a first-class language property whose result appears in the language’s bytecode format as a declared bound that the load-time verifier checks against the analysis result. A Keleusma program whose bytecode declares a specific WCET bound will be rejected at load time if the actual analysis gives a larger bound, which ensures that a bytecode artifact carries its own verification of its resource claims. The property is substantially a synthesis of the definitive-bound tradition that the pre-nineteen-sixty foundations established through Kleene’s primitive-recursive functions, the totality-analysis tradition of Martin-Löf’s type theory, and the industrial WCET-analysis tradition of avionics contexts.
The integration of WCET analysis into the type system is substantially a research direction whose adoption outside Keleusma remains limited as of the mid-twenty-twenties. The pattern of extending static analyses that were previously external tools into first-class language properties is a general direction that the following decade will substantially develop.
Three new statically typed programming languages of the twenty twenties have gained substantial developer attention, though none has yet reached the industrial-adoption levels of Rust or TypeScript.
Zig,
which
Andrew Kelley
introduced
in
February
of
two thousand sixteen
and
which
continued
substantial development
across
the twenty twenties,
became
substantially adopted
as
a modern C alternative
whose
compile-time evaluation facility
and
error-union type discipline,
written !T
for a value
that is either
a T
or
an error,
addressed
several
practical difficulties
of
C programming
without
requiring
Rust’s ownership discipline.
Zig
had not
reached
its version one point zero release
by
mid two thousand twenty-six,
but
its adoption
in
substantial systems programming projects
suggests
that
the language
will
reach
production stability
in
the following years.
The Zig Software Foundation,
established
by Kelley
in
two thousand twenty
as
a five oh one c three nonprofit,
funds
core-contributor development
and
community activities.
Roc, introduced by Richard Feldman and colleagues starting around two thousand nineteen, is a pure functional programming language whose design draws on Elm that the previous article introduces alongside several other language traditions. Roc combines pure functional programming with non-Turing-complete recursion, platforms that provide effects, and compilation to native code through the LLVM infrastructure. The language had not reached a version one point zero release by mid two thousand twenty-six but had substantial developer attention in functional-programming-adjacent contexts.
Verse, which Epic Games announced in March of two thousand twenty-three at the Game Developers Conference, is a functional logic programming language whose design was substantially influenced by Simon Peyton Jones, who joined Epic Games in November of two thousand twenty-one following his departure from Microsoft Research. Verse is used primarily as the scripting language for Fortnite content in Epic Games’ Unreal Editor for Fortnite. The language carries substantial functional-logic-programming features that the article on the nineteen seventies covers through Prolog’s declarative discipline.
The twenty twenties have seen substantial development in large language model-assisted programming and proof work, which has begun to influence programming language design and proof-assistant design. Interactive theorem provers including Lean 4 and the Rocq Prover have integrated large language models into their tactic-search and premise-selection mechanisms, which has substantially accelerated the mechanization of mathematical proofs.
The integration raises substantive questions about the epistemology of mechanized proof that the discipline has not yet fully resolved. A proof that a large language model produces and that the proof assistant verifies is a valid formal proof in the sense that the type checker’s guarantee extends to any proof term regardless of its origin. The extent to which the proof should be considered mathematically illuminating rather than merely formally correct remains a matter of active discussion in the mathematical formalization community.
Programming-language-directed large language model work has also begun to influence new language design. Several new languages of the decade carry features that were substantially designed to be accessible to large language models as code-generation targets, including languages with substantially reduced implicit-behavior surfaces and substantially explicit type discipline. The design pattern has substantial precedent in the compact-toolchain discipline that Rust and Zig carry for different but adjacent reasons, namely that a language whose surface carries substantially explicit type discipline and substantially reduced implicit behavior is easier for both human reviewers and mechanical tools to reason about.
The large language model integration into programming is substantially a current-events story that this article does not attempt to fully develop. The periodic surveys that follow this arc will pick up the topic as it develops.
The historical arc closes at the present moment. The periodic current-event surveys that follow this article will pick up new work from the four principal ACM SIGPLAN conferences, namely POPL, ICFP, PLDI, and OOPSLA, that the opener article introduces, alongside substantial industrial announcements and open-source developments that did not originate in the academic literature.
The surveys will be periodic rather than per-week or per-month, because programming language theory does not move fast enough to justify a higher cadence. An annual retrospective covering the year’s work at the four ACM SIGPLAN conferences, along with substantial industrial announcements of the year, is the tentative cadence that subsequent surveys will follow. A specific development that warrants its own article will receive its own article rather than being embedded in a periodic survey.
The reader who arrives at a specific development of the surveys will have the historical arc as its context, which was the instrumental purpose of the arc that the opener article established. Denning’s information-flow lattice in production language form will not appear without the reader having context for the fifty-year gap between the original paper and the production adoption. Refinement types in Liquid Haskell and Keleusma will not appear without the reader having context for the thirty-year gap between Freeman-Pfenning’s formalization and production use. Effect handlers in mainline OCaml will not appear without the reader having context for the fifteen-year gap between Plotkin-Pretnar’s paper and the mainline release.
The gaps between research and production are substantial in programming language theory. The historical arc gives the reader the specific temporal context for each gap, which allows the reader to judge whether a given current-events announcement is a substantive advance or a rediscovery.
The twenty twenties so far have supplied eight things that subsequent work in programming language theory will build on.
First, the fourth HOPL conference proceedings as the standard secondary reference for languages that reached wide adoption by two thousand eleven.
Second, Lean 4 as the primary vehicle for community-driven mechanized mathematics.
Third, the Rocq Prover as the continued vehicle for software-verification-oriented mechanized formal work.
Fourth, OCaml 5 as a mainline production language carrying effect handlers.
Fifth, CompCert, seL4, and HACL asterisk in substantial production deployments in avionics, security-adjacent systems, and browser and operating-system cryptographic infrastructure.
Sixth, refinement types and information-flow labels in embedded scripting languages including Keleusma.
Seventh, worst-case execution time as a first-class language property in selected embedded scripting languages.
Eighth, large language model integration into proof assistants and programming environments as an active research frontier.
The historical arc closes here. The periodic current-event surveys that follow this article will extend the treatment of each of these directions as they develop.
The historical arc that the opener article began closes at the present moment. The seventy-year arc from Alonzo Church’s lambda calculus of the nineteen thirties through the founding of the ACM Symposium on Principles of Programming Languages in nineteen seventy-three to the current state of practice in which several fifty-year-old theorems appear as production language features is a coherent intellectual project with identifiable milestones, established publication venues, and a small number of canonical references that this series has drawn on.
The current state of practice carries substantial evidence that the arc is not finished. Rust and TypeScript have substantial industrial adoption. Lean 4 has substantial adoption in mechanized mathematics. OCaml 5 carries effect handlers in mainline distribution. Keleusma carries information-flow labels, refinement types, and worst-case-execution-time as first-class language properties in an embedded scripting language. The next generation of production language features is already visible in research publications that have not yet reached production but that prior patterns suggest will do so across the following decade.
The periodic current-event surveys that follow this article will pick up each of these directions as they develop. The reader who has followed the arc now has the specific temporal and technical context for each direction, which was the instrumental purpose of the arc that this series was constructed to establish.
The twenty tens took the verification-oriented type features that the previous article covers in their nineteen-nineties and two-thousands research forms and delivered them in production programming languages that substantial industrial software was written in. Rust, whose stable one point zero release appeared in May of two thousand fifteen, brought substructural type discipline into a widely adopted systems programming language through its ownership and borrow-checker mechanisms. F-star and Idris brought dependent-type programming into industrial use as verification-oriented and general-purpose programming languages respectively. Effect handlers matured from Gordon Plotkin and Matija Pretnar’s two thousand nine paper into a working programming discipline that Multicore OCaml and subsequent languages would adopt. Liquid Haskell, published in two thousand fourteen by Niki Vazou and colleagues, brought the liquid-types work of the two thousands into the first production-oriented refinement-type system. Session types, which Kohei Honda and colleagues had introduced in the nineteen nineties, entered industrial use through the multiparty session type program that extended their applicability to substantial distributed protocols. Gradual typing, which Siek and Taha had opened as an intellectual project in two thousand six, reached mainstream adoption through TypeScript, Python type hints, and Ruby type systems. Homotopy type theory, formalized in the Univalent Foundations Program’s two thousand thirteen book, extended Martin-Löf type theory with a specific mathematical structure that had substantial consequences for the interpretation of programs as mathematical objects.
The twenty tens also produced substantial new statically typed programming languages that combined existing techniques into new distributions, including Swift, Kotlin, Elm, Elixir, and Julia. Each language combined several techniques that the previous decades had established into a form that fit a specific industrial demand. The languages were not primary theoretical contributions but each supplied a specific working environment that subsequent programming language research would engage with.
Rust
had begun
as
a personal project
of
Graydon Hoare
at Mozilla
in
two thousand six.
Mozilla
sponsored the project
formally
in
two thousand nine.
The years
between two thousand ten
and two thousand fifteen
saw
substantial redesign
of
the language’s type system
around
what became
the ownership discipline.
The ownership discipline
established that
every value
in a program
had
exactly one owner
at each point in time,
and
that
a value
could be
borrowed
by
other parts of the program
through
references
that
carried
lifetime information
in
their types.
A reference
is written
&T
for an immutable borrow
of a value
of type T,
and
&mut T
for a mutable borrow
that permits
modification
through the reference.
The borrow checker
verified
that
borrows
did not
outlive
the values
they referenced
and that
mutable and immutable borrows
did not
overlap
in ways
that
would violate
the ownership discipline.
The Rust ownership discipline was substantially indebted to the substructural type systems that programming language research had developed across the nineteen nineties and two thousands. Linear types, which Philip Wadler had introduced in his nineteen ninety paper Linear Types Can Change the World, gave each value a use-exactly-once discipline. Affine types, which were a relaxation of linear types, allowed a value to be used at most once. Rust’s ownership discipline adopted an affine treatment by default, extended with a borrowing mechanism that allowed non-consuming access to a value without transferring ownership. The borrow checker implemented the discipline in a form that carried substantial ergonomic engineering alongside its formal foundation.
Rust one point zero appeared on May fifteenth of two thousand fifteen. The release consolidated the ownership discipline, the borrow checker, and a substantial standard library into a stable programming language. Rust’s memory safety guarantees without a garbage collector distinguished it from the other statically typed languages of the following decade, which substantially relied on garbage collection for memory management. Rust became the primary vehicle for systems programming whose performance and memory-safety requirements did not tolerate the overhead of garbage collection.
The language’s adoption extended substantially beyond its initial browser-engine target into operating-system kernels, distributed-systems infrastructure, cryptographic libraries, and substantial industrial software generally. The Linux kernel began accepting Rust code in two thousand twenty-two. Microsoft began rewriting portions of Windows in Rust across the same period. The rewrite pattern, in which industrial software that had been written in C or C++ was rewritten in Rust for memory safety, became the primary industrial motivation for Rust adoption.
Nikhil Swamy and colleagues at Microsoft Research began the F-star project in two thousand eleven. The initial technical report, Microsoft Research Technical Report MSR-TR two thousand eleven-thirty seven, described a dependently typed language for secure distributed programming. The subsequent F-star line extended the language into a general-purpose, verification-oriented, effectful programming language whose type system supported dependent types, refinement types, and monadic effects in a single framework. The project became a collaboration between Microsoft Research, INRIA, the University of Maryland, the École Normale Supérieure Paris, and the IMDEA Software Institute.
F-star compiles verified programs to executable code in OCaml, F sharp, or C. The verification happens at compile time through a combination of the type checker and external satisfiability-modulo-theories solvers, which the previous article on liquid types introduces. The verified-compilation approach allowed F-star to produce substantial industrial verified code, including the miTLS Transport Layer Security implementation and the HACL asterisk cryptographic library. Both artifacts became part of production browser and operating system security infrastructure across the following decade.
Edwin Brady introduced Idris in his two thousand eleven paper IDRIS, Systems Programming Meets Full Dependent Types, delivered at the fifth Programming Languages Meets Program Verification workshop. Idris was designed as a general-purpose dependently typed programming language whose target was practical programming rather than proof-oriented mechanized mathematics. The language provided type-driven development in which the type of a function guided the programmer through the construction of the function’s implementation. The type checker could generate partial implementations from type signatures that the programmer then completed.
Brady published Type-Driven Development with Idris through Manning Publications in two thousand seventeen. The book became the standard introduction to dependently typed programming outside the proof-assistant tradition. Idris 2 appeared in two thousand twenty with substantial redesign around the quantitative type theory that Robert Atkey had developed, which allowed the type system to track resource usage in its types. Idris became substantially the reference implementation of practical dependent-type programming alongside Agda, which the previous article covers.
Gordon Plotkin and Matija Pretnar’s two thousand nine paper Handlers of Algebraic Effects, delivered at the eighteenth European Symposium on Programming, introduced what became known as algebraic effect handlers. The journal version, Handling Algebraic Effects, appeared in Logical Methods in Computer Science volume nine, issue four, in two thousand thirteen. The formalism generalized exception handling from Modula-2 and Ada to a uniform treatment of computational effects including nondeterminism, input-output, concurrency, state, and their combinations.
The algebraic effects and handlers approach
distinguished
between
the operations
that a program
could perform
and
the handlers
that specified
how those operations
were interpreted.
An operation
was
declared
without
a specific implementation.
A program
invoked an operation
by writing
perform op,
which suspended
the program
until
a handler
supplied
an interpretation.
A handler
supplied
the interpretation
by
mapping
each operation
to
a continuation
that
the handler
could
call zero,
one,
or many times
to
resume
the program’s execution,
written
handle e with h
where h
supplies
the interpretation
of every operation
that expression e
might perform.
The mechanism
was
substantially more expressive
than
the monadic approach
that
the previous article on nineteen-nineties Haskell
covers,
in that
it
allowed
effects to be
composed
without
the monad-transformer
apparatus
that
Haskell had required.
Effect handlers matured into a working programming discipline across the decade through several implementations. The Eff language, which Andrej Bauer and Matija Pretnar developed across the early twenty tens following their two thousand ten paper Programming with Algebraic Effects and Handlers, was the first production language that carried effect handlers as a first-class feature. Multicore OCaml, whose development began in two thousand fourteen at Cambridge University and IIT Madras, brought effect handlers into OCaml as the underlying mechanism for its concurrency support. The system would become part of mainline OCaml in version five point zero in two thousand twenty-two. The Koka language, by Daan Leijen at Microsoft Research, combined effect handlers with a row-polymorphic effect type discipline that gave each expression a type carrying the effects it might cause. The Frank language, by Sam Lindley and colleagues, integrated effect handlers into a dependently typed setting.
The effect-handler discipline became substantially the twenty-tens successor to the monadic approach of the previous article. Where monads required a specific monadic type that the program was structured around, effect handlers allowed a program to be written in direct style that made the effects explicit in the operation calls without requiring the program to be restructured into monadic bind chains.
Niki Vazou, Eric L. Seidel, Ranjit Jhala, Dimitrios Vytiniotis, and Simon Peyton Jones published Refinement Types for Haskell at the nineteenth International Conference on Functional Programming in two thousand fourteen. The system, known as Liquid Haskell, took the liquid-types work that Rondon, Kawaguchi, and Jhala had introduced in two thousand eight and integrated it into Haskell as a compiler plugin that verified refinement annotations against the Haskell type system.
A companion paper, LiquidHaskell, Experience with Refinement Types in the Real World, by Vazou, Seidel, and Jhala, appeared at the two thousand fourteen ACM SIGPLAN Symposium on Haskell in Gothenburg, Sweden. The paper reported on the application of Liquid Haskell to substantial Haskell libraries including Data.ByteString, Data.Text, Data.Map, and Data.Vector. The experience established that refinement-type verification was practical at production-library scale and that the resulting refinement annotations carried substantial documentation value for future readers of the code in addition to their verification content.
Liquid Haskell became substantially the first production-scale refinement-type system. Its users were substantially outside the original research group, which distinguished it from prior refinement-type systems whose users had been substantially the systems’ designers. The tool would be used across the following decade in substantial industrial verification work including the Amazon Web Services IronFleet and Vale verified-cryptography projects. Vazou’s two thousand seventeen doctoral dissertation Liquid Haskell, Haskell as a Theorem Prover consolidated the technical treatment of the system.
Session types
had been introduced by
Kohei Honda
in
his nineteen ninety-three paper
Types for Dyadic Interaction,
delivered at
the fourth International Conference
on Concurrency Theory.
The nineteen-nineties formulation
treated
communication between
exactly two parties
over
a single channel.
A session type
such as
!T.S
describes a channel
that sends
a value of type T
and then behaves
as session S,
and
?T.S
describes a channel
that receives
a value of type T
and then behaves
as session S.
The terminated session
is written end.
Nobuko Yoshida
and colleagues
extended
the treatment
to
multiparty session types
in
their two thousand eight paper
Multiparty Asynchronous Session Types,
delivered at
the thirty-fifth Symposium
on Principles of Programming Languages.
The multiparty extension
allowed
session types
to
describe
protocols
involving
arbitrarily many
participating parties.
The twenty tens saw substantial industrial application of multiparty session types. The Scribble protocol description language, developed by Yoshida and colleagues at Imperial College London, became a working notation for describing distributed-system protocols in a form that compilers could translate into executable code in substantial mainstream languages including Java, Python, Go, and Rust. The Mungo tool extended Java with session-type checking of class-method call sequences. The Sesh library extended Haskell with runtime session-type checking.
The technique matured substantially through industrial use cases in the microservices and distributed-systems domains where the specification of interaction protocols between distinct services was a substantial engineering problem. Session types supplied a specific technical framework for that specification that prior program-verification techniques had not addressed directly. Industrial adoption was substantial though not dominant by the end of the decade.
TypeScript,
released by
Microsoft
in
October
of two thousand twelve,
was
the first
industrial-scale
gradually typed language.
The language
was designed by
Anders Hejlsberg,
who had previously
led
the design of
C sharp
at Microsoft.
TypeScript
extended
JavaScript
with
static type annotations
that
the TypeScript compiler
verified
before
compiling
the program
to
JavaScript.
The dynamic type discipline
that
Siek and Taha had introduced
appeared in TypeScript
as
the any type,
which
allowed
values
to
escape
static type checking.
TypeScript’s adoption was substantially rapid across the following decade. Major JavaScript frameworks including Angular, React, and Vue adopted TypeScript as their primary implementation language or as a first-class alternative to untyped JavaScript. By the end of the decade, TypeScript had substantially replaced JavaScript as the default choice for new web-application code in substantial portions of industrial practice.
Python’s type-hint system, introduced in Python 3.5 in September of two thousand fifteen through PEP 484, brought gradual typing to Python. The system did not carry runtime enforcement in the standard Python implementation. Instead, separate type checkers including Mypy, Pyright, Pyre, and Pytype verified type annotations at development time without affecting runtime behavior. The separation of type checking from runtime execution allowed Python to carry type annotations as optional documentation and verification without requiring existing untyped code to be retrofitted with annotations.
Ruby followed a similar path with the RBS type-signature format and the Sorbet type checker that Stripe released publicly in two thousand nineteen. Sorbet brought gradual typing to a substantial industrial Ruby codebase and demonstrated that gradual typing scaled to codebases of millions of lines. The Ruby community subsequently adopted RBS as the standard type-signature format, with type checkers implementing the RBS specification supplied by Stripe and Ruby core team members.
Typed Racket, which the previous article mentions as Typed Scheme before the two thousand ten rename, continued across the decade as the primary academic research vehicle for gradual typing. Sam Tobin-Hochstadt and Matthias Felleisen’s two thousand eight paper The Design and Implementation of Typed Scheme, which predated the rename, had established the technical foundations that Typed Racket continued to develop.
Vladimir Voevodsky and colleagues at the Institute for Advanced Study in Princeton led a Special Year on Univalent Foundations of Mathematics across two thousand twelve and two thousand thirteen. The Special Year produced the book Homotopy Type Theory, Univalent Foundations of Mathematics, published in two thousand thirteen under a Creative Commons license by The Univalent Foundations Program. The book was substantially a collective work of the participants in the Special Year rather than a single-author monograph.
Homotopy type theory extended Martin-Löf’s type theory that the previous article on the nineteen seventies covers with what became known as the univalence axiom. The axiom stated that equivalent types were equal as mathematical objects. The axiom was substantially controversial within the type theory community because it was not constructive in the traditional sense that Martin-Löf type theory had established. The controversy was resolved substantially through subsequent work on cubical type theory by Cyril Cohen, Thierry Coquand, Simon Huber, and Anders Mörtberg in two thousand fifteen and two thousand sixteen, which provided a constructive formulation of univalence.
The homotopy type theory program had substantial consequences for the interpretation of programs as mathematical objects. Higher inductive types, which the theory introduced, gave type theory a mechanism for representing quotient types and other equivalence-class constructions that prior formulations had handled awkwardly. The Cubical Agda and cubical fragment of Coq made homotopy type theory practical for mechanized mathematical work. The impact on programming language design was substantially indirect, through the influence on subsequent dependent-type systems of languages including Idris and Lean.
Five new statically typed programming languages of the decade would influence subsequent programming language design.
Swift was announced by Apple in June of two thousand fourteen and released publicly in October of the same year. The language was designed by Chris Lattner and colleagues as a successor to Objective-C for Apple’s platforms. Swift combined the object-oriented model of Objective-C with functional-programming influences from Standard ML and Haskell, value-type discipline, and a substantial standard library. The language became the primary programming language for Apple platform development across the following decade.
Kotlin was released by JetBrains in February of two thousand sixteen after initial development starting in two thousand eleven. The language was designed by Andrey Breslav and colleagues as a language whose programs compiled to Java Virtual Machine bytecode and could interoperate seamlessly with existing Java code. Google adopted Kotlin as the primary Android development language in two thousand seventeen, which made Kotlin the default choice for Android application development across the remainder of the decade.
Elm was released by Evan Czaplicki in two thousand twelve. The language was a Haskell-derived purely functional programming language targeting web-browser frontends. Elm consolidated several ideas from the Haskell tradition including purity, immutable data, and algebraic data types into a language whose learning curve was substantially shorter than Haskell’s and whose runtime did not carry the space and time behaviors of lazy evaluation. The language influenced the design of subsequent front-end frameworks including The Elm Architecture pattern that Redux in the JavaScript ecosystem adopted.
Elixir was released by José Valim in two thousand twelve. The language compiled to the Erlang virtual machine bytecode and inherited Erlang’s actor-based concurrency model and fault-tolerance discipline that the article on the nineteen eighties mentions. Elixir provided a substantially more approachable surface syntax than Erlang along with macro-based metaprogramming that gave library designers substantial expressive power. The language became the primary programming language for Erlang-VM-based systems in industrial contexts where the Erlang ecosystem was architecturally appropriate.
Julia was released by Jeff Bezanson, Stefan Karpinski, Viral Shah, and Alan Edelman at the Massachusetts Institute of Technology in two thousand twelve. The language was designed as a dynamically typed language whose just-in-time compilation and multiple-dispatch discipline gave it performance comparable to FORTRAN and C on numerical benchmarks. Julia was intended as a competitor to NumPy-and-Python and MATLAB for scientific computing, and achieved substantial adoption in scientific-computing contexts where the Python performance ceiling was a practical concern.
WebAssembly, which several browser vendors proposed in two thousand fifteen and which reached its one point zero version in two thousand seventeen, provided a portable bytecode that substantial existing programming languages including C, C plus plus, and Rust could compile to. The bytecode was designed for efficient interpretation in web browsers and subsequently extended to server-side and edge-computing runtimes.
WebAssembly’s design drew on the single-pass validation tradition that the stream-based compilers series conclusion covers for its safety-property guarantees. The bytecode carried a fixed-size instruction encoding, a block-structured control flow, and a validation discipline that allowed the entire bytecode module to be verified in a single pass of constant working memory. The validation guarantees established that a well-formed WebAssembly module would not violate memory safety, would not depend on unspecified behavior, and would not execute outside its declared resource bounds.
WebAssembly became substantially the second half of a portability story that had begun with Java bytecode in the previous article. Where Java bytecode had assumed a garbage-collected object-oriented runtime, WebAssembly assumed no runtime services beyond memory allocation, which allowed languages including Rust to compile to WebAssembly without requiring their runtime systems to be substantially reengineered. The Wasmtime, Wasmer, and WasmEdge runtimes established server-side WebAssembly as a working deployment target by the end of the decade.
The twenty tens supplied nine things that subsequent work would build on.
First, Rust as a widely adopted systems programming language with statically enforced memory safety without garbage collection, which established substructural type discipline as a practical technique.
Second, F-star as a working verification-oriented programming language whose verified artifacts appeared in production security infrastructure.
Third, Idris as a working general-purpose dependently typed language outside the proof-assistant tradition.
Fourth, effect handlers as a practical concurrency and effects mechanism through Eff, Koka, Multicore OCaml, and Frank.
Fifth, Liquid Haskell as the first production-scale refinement-type system.
Sixth, multiparty session types as a working technique for distributed-protocol specification.
Seventh, gradual typing at industrial scale through TypeScript, Python type hints, and Ruby Sorbet.
Eighth, homotopy type theory as an extension of dependent-type theory that subsequent proof assistants and programming languages would engage with.
Ninth, WebAssembly as a portable bytecode that statically typed languages could target without requiring runtime services beyond memory allocation.
The next article, A215, covers the twenty twenties to the present.
The twenty tens productionized the verification-oriented type features that prior decades had developed in research settings. Rust brought substructural type discipline into widely adopted industrial use. F-star and Idris brought dependent types into practical programming. Effect handlers matured into a working alternative to monads. Liquid Haskell brought refinement types into practical Haskell development. Session types entered industrial distributed-system practice. Gradual typing reached substantial portions of web, scripting, and enterprise software. Homotopy type theory extended the mathematical foundations of dependent-type theory. WebAssembly established a portable bytecode that did not assume a garbage-collected runtime.
The next article, A215, covers the twenty twenties to the present.
The two thousands were the decade in which several nineteen-nineties research programs crossed the boundary from academic technique to production-oriented tool. Refinement types, which Tim Freeman and Frank Pfenning had formalized in the previous decade, appeared in Patrick Rondon, Ming Kawaguchi, and Ranjit Jhala’s liquid types system, which was the first refinement-type system whose designers targeted production-scale programs as a primary goal. Xavier Leroy and colleagues at the French Institut National de Recherche en Informatique et en Automatique delivered CompCert, the first mechanically verified optimizing compiler for a substantial fragment of C. The Coq proof assistant proved the Four Color Theorem in a formal proof by Georges Gonthier and Benjamin Werner. Ulf Norell at Chalmers University of Technology delivered Agda 2, the first proof assistant whose surface syntax made dependent-type programming accessible to users without extensive proof-theory training. Jeremy Siek and Walid Taha opened the gradual-typing research program that would subsequently inform the design of TypeScript, Python’s type-hint system, and Ruby’s type system. Benjamin Pierce published Types and Programming Languages in two thousand two, consolidating the type-systems literature into a single graduate textbook. The third HOPL conference, held in San Diego in two thousand seven, produced retrospective papers on the major languages of the intervening two decades.
The decade also saw the ascendancy of the industrial dynamic languages that the previous article introduces, namely JavaScript, Python, and Ruby. The three languages were not theoretical contributions in the sense that the developments above are, but their industrial dominance set the environment in which subsequent theoretical work on type systems and verification would land.
Benjamin C. Pierce published Types and Programming Languages through the MIT Press in January of two thousand two. The book consolidated the type-systems literature that the previous article covers into a single graduate textbook whose treatment became the reference for the following two decades.
The book’s approach was substantially indebted to Wright and Felleisen’s nineteen ninety-four syntactic type soundness paper. Every type system that the book presented was accompanied by a formal statement of the language’s syntax and operational semantics, a proof of type soundness in the progress-and-preservation form, and worked examples that demonstrated the type system’s expressive power and its limits. The book’s exercises required the reader to work through the proofs directly, which made it practical as a teaching text rather than only a reference.
The book covered untyped lambda calculus, simply typed lambda calculus, subtyping, recursive types, polymorphism including System F, higher-order polymorphism through System F omega, type reconstruction including Hindley-Milner, existential types, type operators and kinding, and higher-order subtyping including F sub. The chapters on each topic were substantially self-contained, which allowed the book to be used selectively in courses whose scope did not require the full sweep.
A companion volume, Advanced Topics in Types and Programming Languages, edited by Pierce and published in two thousand five, extended the treatment to dependent types, type theory for practical programming, substructural type systems including linear types, and several specialized applications. The two volumes together became the standard graduate curriculum for type systems in the following decade.
Pierce also began the Software Foundations project, a Coq-based curriculum for programming language theory, whose first materials were developed around two thousand seven at the University of Pennsylvania and whose successor volumes would extend across the twenty tens. Software Foundations took Types and Programming Languages one step further by mechanizing every theorem in the Coq proof assistant and requiring the reader to complete the proofs interactively. The project became the standard vehicle for teaching mechanized programming language theory in the following decades.
The Coq proof assistant, whose development the previous article covers into its stabilized late-nineteen-nineties form, saw substantial mathematical work across the two thousands. The Four Color Theorem, which had first been proved by Kenneth Appel and Wolfgang Haken in nineteen seventy-six using substantial computer assistance that readers could not verify by hand, was proved formally in Coq by Georges Gonthier and Benjamin Werner in two thousand five. Gonthier’s paper A Computer-Checked Proof of the Four Colour Theorem described the mechanization, which verified the reducibility of approximately six hundred configurations that the classical proof had needed.
The Coq proof was substantially larger in scope than any prior mechanized-mathematics work. It required Gonthier to develop a specific proof-engineering discipline called small-scale reflection, which became known as SSReflect, that allowed proof scripts to manipulate propositions by computation rather than by explicit case analysis. The SSReflect discipline made subsequent large-scale Coq developments practical. Gonthier went on to lead the Mathematical Components library, which formalized substantial portions of abstract algebra in Coq across the two thousands and twenty tens, culminating in the two thousand twelve formalization of the Feit-Thompson theorem that the previous article mentions.
Ulf Norell at Chalmers University of Technology in Gothenburg delivered Agda 2 in his September two thousand seven doctoral dissertation Towards a Practical Programming Language Based on Dependent Type Theory. Agda 2 succeeded an earlier Agda that Catarina Coquand and colleagues had developed at Chalmers in the mid nineteen nineties, but the new implementation was substantially different in design and was intended to make dependent-type programming accessible to practical programmers.
Agda 2’s design emphasized the programming aspects of Martin-Löf’s type theory over its proof aspects. The surface syntax was substantially closer to Haskell than to the tactic-based Coq syntax, which made Agda 2 programs readable as ordinary functional programs whose types were substantially more expressive than those of ordinary functional programs. The system became the primary teaching vehicle for dependently typed programming in the following decade, alongside Coq’s continued use for mechanized mathematics.
The Isabelle system, which the previous article covers, also continued to develop across the decade. Isabelle/HOL became the primary vehicle for mechanized verification of security protocols and operating system kernels. The seL4 microkernel verification effort, led by Gerwin Klein at the National ICT Australia, began in two thousand four and would produce its first mechanically verified implementation in two thousand nine.
Xavier Leroy at the French Institut National de Recherche en Informatique et en Automatique began the CompCert project in two thousand five. CompCert was intended as a mechanically verified optimizing compiler for a substantial fragment of the C programming language, called Clight, that the earlier article on the nineteen seventies introduces as Dennis Ritchie’s work. The project was funded by the French national research agencies Agence nationale de la recherche and INRIA.
Leroy’s approach was to program the compiler in Coq using the Gallina functional programming language that Coq provides, and to prove the compiler’s correctness in Coq in the same development. The correctness statement was that the compiler’s output had the same observational behavior as the compiler’s input under the C language semantics. The proof covered every optimization pass that the compiler performed, including common subexpression elimination, constant propagation, register allocation, and instruction scheduling.
CompCert’s two thousand six POPL paper delivered the initial technical announcement. The two thousand nine Journal of Automated Reasoning paper A Formally Verified Compiler Back-End provided the full technical treatment. The project received the two thousand twenty-one ACM Software System Award for being the first practically useful optimizing compiler targeting multiple commercial architectures whose correctness was mechanically verified.
CompCert was substantially the first demonstration that mechanical verification of production-scale software was practical. Subsequent projects including the CakeML verified ML compiler and the seL4 microkernel followed the CompCert methodology of writing the artifact in a proof assistant’s programming language and proving correctness in the same development. The methodology became the standard technique for verified-software engineering in the following decade.
Patrick Rondon, Ming Kawaguchi, and Ranjit Jhala at the University of California, San Diego introduced liquid types in their two thousand eight paper Liquid Types, delivered at the Programming Language Design and Implementation conference, pages one hundred fifty-nine through one hundred sixty-nine. The system extended the Freeman-Pfenning refinement-type program with two specific technical contributions that made practical adoption substantially easier than prior refinement-type systems had allowed.
The first contribution
was
predicate abstraction
for
refinement inference.
Liquid types
introduced
a fixed language
of predicates,
substantially simpler
than
the full first-order logic
that
prior refinement-type systems
had accepted
as refinements,
that
consisted of
comparisons
between
program variables
and
arithmetic expressions.
A representative liquid type
is
{v : Int | 0 <= v && v < n},
which
denotes
integers v
that are
non-negative
and strictly less than
another program variable n.
The example
is
the classic array-index refinement
that
allows
a static
array-bounds check
to eliminate
the corresponding runtime bounds check.
The restriction
made
refinement inference decidable,
which
allowed the compiler
to
infer refinements
automatically
rather than
requiring
the programmer
to
annotate every function
with
its refinement.
The trade-off
that liquid types accepted
was
that
some
refinement predicates
that
prior systems
could express
were
no longer expressible.
The predicate language
was
chosen
to cover
the substantial majority
of
practical refinement use cases.
The second contribution was integration with external solvers in the satisfiability-modulo-theories tradition, often abbreviated SMT. Liquid types generated verification conditions from the refinement inference and discharged them using an external SMT solver. The integration allowed the compiler to handle substantial arithmetic reasoning without implementing the arithmetic reasoner directly. The approach became standard in subsequent refinement-type systems and in production verification tools generally.
The two thousand eight system targeted OCaml. Subsequent work by the same research group would extend the approach to Haskell in the two thousand fourteen Liquid Haskell system, which the next article in this series develops. Liquid Haskell became the first production-oriented refinement-type system whose users were substantially outside the original research group.
Jeremy Siek and Walid Taha introduced gradual typing in their two thousand six paper Gradual Typing for Functional Languages, delivered at the Scheme and Functional Programming Workshop, pages eighty-one through ninety-two. Gradual typing was a discipline for combining static and dynamic type checking in a single language that allowed the programmer to selectively annotate parts of a program with static types while leaving other parts dynamically typed.
The gradual-typing approach
distinguished
a special type
called
the dynamic type,
written
? or Dyn,
that
represented
values whose type
was
not known
statically.
A function
whose parameter
had
type ?
could be called
with
values of any type.
A function
whose parameter
had
type Int
required
its callers
to
supply
integer values,
but a caller
whose value
had
type ?
could
supply the value
after
a runtime type check.
The type system
inserted
the runtime type checks
at
the boundary
between
statically typed
and dynamically typed
code.
The compatibility rule
was
formalized
as
a consistency relation
T1 ~ T2
between two types,
under which
? ~ T
and
T ~ ?
hold
for every type T,
and
identical types
are consistent
with themselves.
The consistency relation
replaced
the type-equality check
of
a fully statically typed language
with
a check that permitted
the dynamic type
to
match anything.
Gradual typing was substantially an intellectual response to the ascendancy of dynamic languages that the same decade saw. The intellectual project established that static and dynamic type checking were not mutually exclusive approaches, and that a language could support both in a principled way that preserved the guarantees of each.
The gradual-typing research program would develop substantially across the following decade. Typed Scheme, which became Typed Racket after the Scheme community adopted the Racket name in two thousand ten, was the first production-scale gradually typed language. TypeScript, which Microsoft released in two thousand twelve, brought gradual typing to JavaScript. Python’s type-hint system, introduced in Python 3.5 in two thousand fifteen, brought gradual typing to Python. Ruby’s RBS type signatures and Sorbet type checker, released in the twenty tens, brought gradual typing to Ruby. The next article in this series covers these developments.
The third History of Programming Languages conference was held in San Diego, California, from June ninth through June tenth of two thousand seven. The conference followed the standard HOPL format that HOPL I in nineteen seventy-eight had established and HOPL II in nineteen ninety-three had continued, namely retrospective papers by the designers of significant programming languages of the intervening period.
HOPL III produced substantial retrospectives on several languages of the nineteen eighties and nineteen nineties that this series also covers, including AppleScript, BETA, C++, Emerald, Erlang, Haskell, High Performance FORTRAN, Icon, Lua, Modula-2 and Oberon, Self, Statecharts, and ZPL. The Haskell retrospective, A History of Haskell, Being Lazy with Class, by Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler, became the standard secondary reference for Haskell’s history that this series has drawn on.
The conference continued the pattern that HOPL I and HOPL II had established. Each retrospective paper was substantially a design memoir written by the language’s designer or design team, with technical detail about the design decisions that had been made and the reasons that they had been made. The proceedings became the primary source for the design history of the languages covered, supplementing the design documents of the languages themselves.
Three new statically typed programming languages of the decade would influence subsequent programming language design in substantive ways.
Martin Odersky at the École Polytechnique Fédérale de Lausanne in Lausanne, Switzerland, began the design of Scala in two thousand one. Odersky had previously worked on Generic Java and the javac compiler at Sun Microsystems. Scala was intended as a language that combined the strengths of object-oriented programming that the article on the nineteen eighties covers and functional programming that the article on the nineteen nineties covers, while running on the Java Virtual Machine that Java made available. An internal release appeared in late two thousand three, and a public release followed in early two thousand four. Scala 2.0 appeared in March of two thousand six. Odersky published Programming in Scala through Artima Press in two thousand eight, which became the standard reference document for the language.
F sharp was developed at Microsoft Research Cambridge by Don Syme and colleagues across the decade. The language was substantially an OCaml derivative targeting the Microsoft dot-NET runtime, with extensions for asynchronous programming, computation expressions that provide a monadic do-notation form, and type providers that allow external data schemas to be imported as type definitions. F sharp became part of the official Microsoft Visual Studio distribution in two thousand ten, which made it one of the first statically typed functional languages to receive first-party support from a major operating-system vendor.
Rich Hickey released Clojure in two thousand seven. Clojure was a Lisp dialect targeting the Java Virtual Machine, extending the LISP tradition that the article on the nineteen sixties covers with several concurrency-oriented features including software transactional memory, persistent immutable data structures, and core.async channels. The persistent data structures were substantially indebted to Phil Bagwell’s two thousand one paper on hash array mapped tries, which Hickey adapted into the Clojure vector and hash-map implementations. Clojure became a substantial industrial programming language across the following decade, particularly in financial-technology and data-processing contexts.
The two thousands saw the industrial ascendancy of three dynamic languages that the previous article introduces, namely Python, Ruby, and JavaScript. The three languages became the primary tools for substantial industrial software across the decade, which changed the environment in which subsequent programming language research would land.
Ruby had begun in nineteen ninety-five by Yukihiro Matsumoto in Japan, but its industrial adoption began substantially with the two thousand four release of Ruby on Rails by David Heinemeier Hansson, which established Ruby as a primary web-application development language. Ruby on Rails introduced what became known as the convention-over-configuration programming style, which would influence subsequent web frameworks across languages.
Python saw its industrial ascendancy begin with the release of NumPy by Travis Oliphant and colleagues in two thousand six, which consolidated the earlier Numeric and numarray scientific-computing libraries into a single implementation. NumPy provided efficient n-dimensional array operations that made Python competitive with FORTRAN and C for numerical work, which established Python as the primary programming language for scientific computing.
JavaScript saw its industrial ascendancy begin with the release of the V8 JavaScript engine by Google in two thousand eight alongside the Chrome browser. V8 made JavaScript execution substantially faster than prior implementations, which enabled substantial web applications to be written primarily in JavaScript running in the browser. The Node.js runtime, released in two thousand nine by Ryan Dahl, extended V8 into a server-side runtime that made JavaScript usable as a general-purpose programming language outside the browser.
The three languages together became the industrial substrate of the decade. The environment they created, in which substantial industrial software was written in dynamically typed languages, established the practical motivation for the gradual-typing research program that Siek and Taha had opened.
Koen Claessen and John Hughes at Chalmers University of Technology introduced QuickCheck in their two thousand paper QuickCheck, A Lightweight Tool for Random Testing of Haskell Programs, delivered at the ACM SIGPLAN International Conference on Functional Programming. QuickCheck was a Haskell library that provided what became known as property-based testing, namely a testing methodology in which the programmer specifies properties that the program under test should satisfy and the testing framework generates random test inputs to attempt to falsify the properties.
QuickCheck was substantially an application of Wadler’s monadic programming that the previous article covers. The library used Haskell’s type-class mechanism to associate random-value generators with each type and Haskell’s monadic apparatus to compose generators for composite types from generators for their components. The composition mechanism made QuickCheck substantially easier to use than prior random-testing tools had been.
The property-based-testing methodology spread substantially across languages in the following decade. QuickCheck implementations appeared for OCaml, Scala, Python, Ruby, and JavaScript. The Haskell community extended QuickCheck into QuickSpec, which inferred properties by random generation rather than requiring the programmer to supply them. Property-based testing became a standard technique in the verification-adjacent tooling of statically typed functional programming languages.
The two thousands supplied eight things that the following decades consumed.
First, Types and Programming Languages as the standard graduate-level type-systems reference. Second, Software Foundations as the standard vehicle for mechanized programming language theory instruction. Third, mechanically verified compilation through CompCert, which would influence CakeML, seL4, and subsequent verified-software projects. Fourth, practical dependent-type programming through Agda 2. Fifth, liquid types as the technical foundation for production refinement-type systems. Sixth, gradual typing as the intellectual foundation for TypeScript, Python type hints, and Ruby type systems. Seventh, Scala, F sharp, and Clojure as statically typed languages combining functional and object-oriented programming on production runtimes. Eighth, property-based testing as a practical verification technique across languages.
The next article, A214, covers the twenty tens.
The two thousands consolidated each research program that the nineteen nineties had opened into a production-oriented tool or a mature intellectual framework. Refinement types crossed into the production track. Mechanical verification of compilers became a practical technique. Proof assistants proved substantial mathematical theorems. Type theory received its consolidation textbook. Gradual typing opened as an intellectual response to the industrial ascendancy of dynamic languages. The following decade would take each of these into practical language design.
The next article, A214, covers the twenty tens.
The nineteen nineties took each research program that the nineteen eighties had consolidated and produced a shipping product, a formal definition, or a mechanized system that subsequent decades would build on. The Definition of Standard ML appeared as a book in nineteen ninety. The Haskell language committee formed in the previous decade delivered Haskell 1.0 in April of the same year and consolidated the language in Haskell 98 by the end of the decade. Objective Caml, built on the same French INRIA lineage that had begun as Caml in the nineteen eighties, first shipped in nineteen ninety-six. Monadic effects, which Eugenio Moggi’s nineteen eighty-nine paper had introduced, reached practical use in Haskell through Philip Wadler and Simon Peyton Jones’s papers across nineteen ninety-two and nineteen ninety-three. Refinement types, which Tim Freeman and Frank Pfenning formalized in nineteen ninety-one at Carnegie Mellon University, established the research program that production refinement-type systems of the two thousands would develop. Andrew Wright and Matthias Felleisen gave type soundness a mechanical proof technique in their nineteen ninety-four paper, which became the standard method for proving type systems correct. The Coq proof assistant took its modern form across the decade. Andrew Myers extended Denning’s information-flow lattice to JFlow in his nineteen ninety-nine doctoral work. The International Conference on Functional Programming was founded in nineteen ninety-six. The second HOPL conference in Cambridge, Massachusetts, in nineteen ninety-three produced its proceedings.
The decade also produced the industrial programming languages that most software of the following decades would be written in, namely Java, JavaScript, and Python. These languages were not substantially theoretical contributions, but their appearance in the same decade as the theoretical consolidations above changed the environment in which subsequent programming language research would land.
Robin Milner, Robert Harper, and Mads Tofte completed the Definition of Standard ML in nineteen ninety. The book was published by the MIT Press. The Definition gave Standard ML a formal specification of its syntax, static semantics, and dynamic semantics that different implementers could target without diverging. The specification used operational semantics in the style that Gilles Kahn had introduced in the nineteen eighties and that Andrew Wright and Matthias Felleisen would formalize into a proof technique later in the decade.
The Definition became the reference document for Standard ML through the following decade. A Commentary on Standard ML by the same three authors appeared in nineteen ninety-one from the MIT Press, providing the explanatory material that the Definition itself did not carry. The Definition of Standard ML, Revised appeared in nineteen ninety-seven, also from the MIT Press, correcting technical errors in the nineteen ninety edition and consolidating five years of implementation experience.
Standard ML was not the only ML dialect of the decade. The French Institut National de Recherche en Informatique et en Automatique, called INRIA, had developed Caml across the nineteen eighties under Gérard Huet’s Formel team. Xavier Leroy designed Caml Light in nineteen ninety and nineteen ninety-one as a bytecode-interpreted variant that ran on small desktop machines, which made the language usable in teaching contexts where the Standard ML implementations of the same period were too large. Damien Doligez implemented the sequential garbage collector.
Leroy released Caml Special Light in nineteen ninety-five, which added a native-code compiler whose performance was comparable to C++ on numerical benchmarks. Caml Special Light also introduced a module system inspired by the Standard ML module system of the previous decade. Didier Rémy and Jérôme Vouillon extended the language with an expressive type system for objects and classes, which was integrated into Caml Special Light to produce Objective Caml, first released in nineteen ninety-six. The language was renamed OCaml in two thousand eleven. The original Objective Caml carried the ML lineage through to the present-day OCaml, which remains one of the two dominant statically typed functional languages of industrial practice alongside Haskell.
The Haskell committee that formed at the nineteen eighty-seven Functional Programming and Computer Architecture conference in Portland, Oregon, that the previous article describes, completed its first design across nineteen eighty-eight and nineteen eighty-nine. The Haskell version 1.0 Report appeared on April first, nineteen ninety. The report was one hundred twenty-five pages and was edited by Paul Hudak and Philip Wadler. Simon Peyton Jones joined as co-editor for the Haskell version 1.1 Report in August of nineteen ninety-one and took on sole editorship of subsequent reports.
The language went through several revisions across the decade, each of which extended the surface language with features that implementers and users had found necessary. Haskell 1.3 introduced monadic input-output, constructor classes, and records. Haskell 1.4 consolidated the Prelude library. The community converged on a stable specification at the end of the decade called Haskell 98, whose report was originally published in February of nineteen ninety-nine. The Haskell 98 specification was intended as a stable, minimal, portable version of the language that could serve as a teaching base and as a foundation for future extensions. It became the reference document for Haskell until Haskell 2010 appeared in the twenty tens.
The second HOPL conference, held in Cambridge, Massachusetts, in nineteen ninety-three, produced substantial retrospective papers on each of the major languages of the intervening two decades. The proceedings included papers on FORTRAN, LISP, Prolog, C, Pascal, Smalltalk, and others. The proceedings became the standard secondary reference for the history of those languages.
Philip Wadler’s nineteen ninety-two paper The Essence of Functional Programming, delivered at the nineteenth Symposium on Principles of Programming Languages, demonstrated that monads in Moggi’s sense, which the previous article introduces, could be used as a practical programming technique rather than only as a semantic device. Wadler’s tutorial paper Monads for Functional Programming, delivered at the Marktoberdorf Summer School in nineteen ninety-two, became the standard reference for practical monadic programming.
Simon Peyton Jones and Philip Wadler’s nineteen ninety-three paper Imperative Functional Programming, delivered at the twentieth Symposium on Principles of Programming Languages, introduced the input-output monad that Haskell subsequently adopted. The paper established that a purely functional language could handle input, output, state, and other effects through the monadic apparatus without extending its type system and without compromising the language’s referential-transparency guarantee.
Haskell 1.3
adopted
monadic input-output
in nineteen ninety-six.
Monadic do-notation,
which
allowed
a program
to be written
in
an imperative-looking style
that
desugared
to
monadic bind operations,
became
standard
in Haskell 98.
The do-notation
took
Peyton Jones and Wadler’s
functional-style monadic construction
and made it
syntactically indistinguishable
from
an imperative program
at
the point of use.
A block written
do x <- m; body
desugars to
m >>= (λx. body),
where >>=
is the monadic bind
operation
that
the previous article
introduces.
The desugaring
substantially reduced
the readability barrier
to
using monads
in practice.
The monadic apparatus extended substantially beyond Haskell. Scala’s for-comprehensions, introduced in the two thousands, are monadic do-notation under a different name. Rust’s Result and Option monads, and the question-mark operator that desugars to monadic bind, are downstream of the monadic tradition that the nineteen nineties Haskell work established. F-sharp’s computation expressions are also a monadic do-notation mechanism.
Timothy Freeman and Frank Pfenning introduced refinement types in their nineteen ninety-one paper Refinement Types for ML, delivered at the Programming Language Design and Implementation conference in Toronto, Ontario, from June twenty-sixth through June twenty-eighth of nineteen ninety-one. Both authors were at the Carnegie Mellon University School of Computer Science.
A refinement type
is
a type
carrying a predicate
that
every value of the type
must satisfy.
For example,
the type
{x : Word | x > 0}
denotes
positive integers,
namely
the values x
of type Word
that
satisfy
the predicate x > 0.
Refinement types
extend
the type system
with
a mechanism
for
expressing
constraints
that
ordinary types
cannot express.
The Freeman-Pfenning system
was designed
to
preserve
the decidability
of
ML’s type inference
while
allowing
more errors
to be caught
at compile time.
The Freeman-Pfenning system handled a subset of Standard ML. The refinements were sort constraints over inductive data types, which allowed the compiler to distinguish between different subsets of the same type by the refinement predicate. An example was distinguishing sorted lists from unsorted lists at the type level. The type system proved that functions that required sorted input would not be called with unsorted lists, without runtime checks.
The Freeman-Pfenning program was substantially ahead of its practical adoption. Refinement types in the Freeman-Pfenning tradition would reach practical use in the two thousands through the Liquid Haskell system by Ranjit Jhala and colleagues. The next article in this series develops the two-thousands adoption. Production adoption of refinement types, including in languages such as F-star that combine refinement types with dependent types, would occur in the twenty tens. The article after that covers the twenty-tens adoption.
Andrew Wright and Matthias Felleisen published A Syntactic Approach to Type Soundness in Information and Computation volume one hundred fifteen, issue one, in nineteen ninety-four. The paper gave a mechanical proof technique for type soundness that became the standard method for proving type systems correct.
The technique
involves
proving
two theorems
about
a language’s
operational semantics
and
its type system.
The preservation theorem
states
that
a well-typed term
remains
well-typed
after
one step
of
execution,
written
if Γ ⊢ e : τ and e → e', then Γ ⊢ e' : τ.
The progress theorem
states
that
a well-typed term
is either
in
a terminal state
or
has
a defined
next step
of execution,
written
if ∅ ⊢ e : τ, then e is a value or e → e' for some e'.
Together
the two theorems
establish
that
a well-typed program
does not
get stuck,
namely
that
it cannot
reach
a state
where
execution
would need to continue
but no rule applies.
The technique depended on two enablers. The first was subject reduction theorems from combinatory logic, which Curry and Feys had developed in the nineteen fifties and nineteen sixties. The second was small-step operational semantics in the Plotkin structural style of the nineteen eighties, which had made the reduction relation formal enough to prove theorems about. The Wright-Felleisen paper adapted subject reduction to the Plotkin small-step form and demonstrated that the resulting proof scaled from polymorphic functional languages to imperative languages with references, exceptions, continuations, and similar features.
The syntactic approach became the dominant method for type soundness proofs in subsequent decades. Modern textbook treatments of type systems, including Benjamin Pierce’s two thousand two book Types and Programming Languages, adopt the technique as the standard method. Every subsequent formalized type system that includes a soundness proof uses progress and preservation in the Wright-Felleisen sense.
The Coq proof assistant took its modern form across the nineteen nineties. Gérard Huet and Thierry Coquand had begun a first implementation of the Calculus of Constructions at INRIA in nineteen eighty-four. The first public release appeared in nineteen eighty-nine. The system was renamed Coq around the end of nineteen eighty-nine, and the Calculus of Inductive Constructions, which added inductive types to the Calculus of Constructions, was integrated in nineteen ninety-one. Christine Paulin-Mohring joined the project as a CNRS researcher at the LIP laboratory of the École Normale Supérieure de Lyon in nineteen ninety. The project was subsequently led jointly by Huet at INRIA and Paulin-Mohring at Lyon.
Coq’s development across the decade established it as the reference proof assistant for Martin-Löf-style dependent type theory. The previous article covers the theoretical foundations of the type theory. Coq implements those foundations with tactic-based proof construction in the LCF tradition that the same article also describes. The system became the vehicle for substantial mechanized-mathematics work across the following decades, including the Feit-Thompson theorem proof in Coq completed in twenty twelve by Georges Gonthier and colleagues.
Other proof assistants of comparable maturity appeared in the same decade. Prototype Verification System, called PVS, was released by SRI International in nineteen ninety-two. The Isabelle system, which had begun in the late nineteen eighties as a generic proof-assistant framework by Lawrence Paulson at Cambridge, matured across the decade into its principal instantiation, Isabelle/HOL, which supported higher-order logic. The HOL system by Michael Gordon at Cambridge continued its development. The four systems together, namely Coq, PVS, Isabelle, and HOL, established that mechanized theorem proving was a practical discipline that subsequent decades would develop.
Andrew Myers completed his doctoral work at the Massachusetts Institute of Technology in nineteen ninety-nine. His thesis system, JFlow, was an extension of Java that added statically checked information-flow annotations. The paper JFlow, Practical Mostly-Static Information Flow Control appeared at the twenty-sixth Symposium on Principles of Programming Languages in San Antonio, Texas, in January of nineteen ninety-nine.
JFlow built on Denning’s nineteen seventy-six lattice model that the earlier article on the nineteen seventies introduces. It added three specific technical contributions. The decentralized label model allowed multiple principals to own distinct security policies that composed into a single lattice without requiring a central authority. Label polymorphism allowed a function to accept values of different security classes by abstracting over the label. Runtime label checking allowed the type system to defer some information-flow decisions to execution time when static checking was too restrictive.
JFlow was the first practical demonstration that Denning’s lattice model could be implemented as a source-language type discipline in an industrial-style language. Myers joined Cornell University as a faculty member following his doctoral work and continued the JFlow line as Jif, which became the maintained implementation. The nineteen ninety-nine POPL paper received the ACM POPL Most Influential Paper Award in two thousand nine.
The first International Conference on Functional Programming was held in Philadelphia, Pennsylvania, from May twenty-fourth through May twenty-sixth of nineteen ninety-six. The conference was sponsored by the ACM Special Interest Group on Programming Languages in association with the International Federation for Information Processing Working Group 2.8 on Functional Programming.
ICFP replaced two prior biennial conferences, namely Functional Programming and Computer Architecture, called FPCA, and LISP and Functional Programming, called LFP. The consolidation into a single annual venue was a substantive editorial decision. It signaled that the functional programming community was large enough to support an annual conference of its own and that the community did not need to distinguish between its architecture-oriented and its language-oriented subcommunities.
ICFP became the primary publication venue for functional programming research in the following decades. The conference publishes work on Haskell, Standard ML, OCaml, Scheme, and adjacent languages, as well as theoretical work on lambda calculi, type systems, and denotational semantics that does not have a natural home at POPL. Every article in subsequent parts of this series that names a specific functional-programming result after nineteen ninety-six draws on work that ICFP substantially published.
The nineteen nineties also produced three industrial programming languages that most software of the following decades would be written in. The three languages are not substantial theoretical contributions in the sense that the other developments covered in this article are, but they changed the environment in which subsequent programming language research landed.
Java was released by Sun Microsystems in May of nineteen ninety-five. The language was designed by James Gosling and colleagues starting in nineteen ninety-one as part of an internal Sun project originally called Oak. Java carried Simula sixty-seven’s object-oriented model that the nineteen sixties introduced into a language whose runtime system included automatic garbage collection, bytecode-based portability, and a substantial standard library. Java was the first mainstream industrial language to combine these features into a single distribution.
JavaScript was released by Netscape Communications in December of nineteen ninety-five as part of Netscape Navigator two point zero. The language was designed by Brendan Eich across a ten-day period in May of nineteen ninety-five. JavaScript combined LISP-style closures that the nineteen sixties introduced with Java-style syntax in a way that its designers had not substantially reflected on before its release. The language would subsequently become the primary browser-side scripting language and, by the twenty tens, one of the most-used programming languages by any measure.
Python was released by Guido van Rossum in February of nineteen ninety-one. The language had begun at the Centrum Wiskunde en Informatica in Amsterdam as a successor to the ABC language that van Rossum had worked on in the late nineteen eighties. Python combined LISP-style dynamic typing, Miranda-style off-side-rule syntax that the previous article introduces, and Modula-style module structure that the nineteen seventies introduces into a language that was substantially easier to teach than its industrial contemporaries. Python became the primary programming language for scientific computing and substantial portions of web development across the following decades.
The three languages were not first movers on any specific technical dimension. They combined existing techniques into distributions whose combined feature sets matched practical demand in industrial contexts better than the specialized research languages of the same period could. The pattern would repeat in subsequent decades with languages including Ruby, C-sharp, Go, and Rust, each of which took existing techniques and combined them into a distribution that fit a specific practical demand.
The nineteen nineties supplied eight things that the following decades consumed.
First, Standard ML as a formally specified language with implementations that matched the specification. Second, OCaml as a working industrial-strength statically typed functional language. Third, Haskell as a stable community-consensus lazy functional language with Haskell 98 as its reference document. Fourth, monadic effects as a practical programming technique through the input-output monad and do-notation. Fifth, refinement types as a formalized research program awaiting production adoption. Sixth, the syntactic type-soundness proof technique as the standard method for proving type systems correct. Seventh, Coq, PVS, Isabelle, and HOL as practical proof assistants. Eighth, Denning’s information-flow lattice in practical language form through JFlow.
The nineteen nineties also established the industrial-programming environment in which subsequent theoretical work would land, through Java, JavaScript, and Python.
The next article, A213, covers the two thousands.
The nineteen nineties consolidated each research program that the nineteen eighties had opened. Standard ML and OCaml gave the ML tradition its industrial forms. Haskell gave the lazy functional programming community its shared language. Monads became a practical programming technique. Refinement types formalized. Type soundness became a mechanical proof. Proof assistants became practical for substantial mathematical work. Information-flow control reached its first practical language form. ICFP consolidated the functional-programming publication venue.
The decade also established Java, JavaScript, and Python as the industrial-programming environment in which subsequent theoretical work would land. The environment would condition the design decisions of subsequent research languages in ways that purely theoretical treatments could not.
The next article, A213, covers the two thousands.
The nineteen eighties took the theoretical results of the previous decade and turned them into working research programs. The Hindley-Milner algorithm became the type system of Standard ML, whose informal development across the decade would culminate in the nineteen ninety Definition that fixed the language. The Miranda language demonstrated that lazy functional programming was practical as a commercial product. Category theory crossed from a specialty of denotational semanticists into a working tool of programming language design, principally through John Reynolds’s parametricity theorem and Joachim Lambek and Philip Scott’s textbook consolidation of the categorical logic program. Effect systems were formalized in John Lucassen and David Gifford’s Massachusetts Institute of Technology work on polymorphic effect systems. Object-oriented programming, which Simula sixty-seven had established in the nineteen sixties, matured through the Smalltalk-80 book, the emergence of C++, and the founding of the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, which is almost always called OOPSLA, in November nineteen eighty-six.
The decade did not open substantially new research directions of the sort that the nineteen seventies had opened. It consolidated each of them into a working program that subsequent decades would develop.
Alain Colmerauer’s Marseille group had continued the development of Prolog across the nineteen seventies into what became Prolog II in nineteen eighty-two. Prolog II extended the base Prolog language with a decision procedure for rational trees, which extended unification from finite terms to infinite terms that could be represented as regular trees. The extension allowed Prolog to handle certain grammar-like specifications that the base language could not.
The more consequential development of the decade was David H. D. Warren’s Warren Abstract Machine. Warren published An Abstract Prolog Instruction Set as SRI International Technical Note three hundred nine in October of nineteen eighty-three. The technical note introduced what came to be called the WAM, which is an abstract machine for efficient execution of Prolog programs that carried a specialized memory architecture including a heap for term storage, a stack for environments and choice points, a trail for undo information on backtracking, and a code area for compiled instructions. The WAM came with a tailored instruction set that compiled Prolog clauses into low-level operations.
The WAM became the de facto compilation target for Prolog implementations in the following decades. Every subsequent performant Prolog implementation either implemented the WAM directly or implemented a variant of it. Hassan Aït-Kaci’s nineteen ninety-one book Warren’s Abstract Machine, A Tutorial Reconstruction, published by the MIT Press, gave the WAM a definitive tutorial exposition that made the compilation technique accessible to implementers outside the original Edinburgh circle.
Prolog also saw its first standardization efforts in the decade. The Japanese Fifth Generation Computer Systems project, which the Japanese Ministry of International Trade and Industry launched in nineteen eighty-two, selected Prolog as the primary programming language of the project and funded a substantial body of implementation and language-standardization work. The project did not achieve its stated goals by its nineteen ninety-two conclusion, but it produced substantial secondary results including parallel Prolog implementations and constraint logic programming systems. ISO Prolog standardization began in the late nineteen eighties and produced its first standard in nineteen ninety-five.
Robin Milner’s ML, which had been developed in the nineteen seventies as the metalanguage of the Edinburgh LCF theorem prover, became the subject of a serious language-design effort in the mid nineteen eighties. The effort was intended to produce a language definition that different implementers could target without diverging. Robin Milner, Robert Harper, and Mads Tofte began work on what became the Definition of Standard ML in the middle of the decade at Edinburgh and, later, at Carnegie Mellon University and the University of Copenhagen. The Definition was published by the MIT Press in nineteen ninety. The decade’s ML work was substantially the development of the material that the Definition consolidated.
Two implementations of the language were developed in the decade. Standard ML of New Jersey, begun in nineteen eighty-six at AT&T Bell Laboratories and Princeton University by Andrew Appel, David MacQueen, and colleagues, became the reference implementation for the research community. Poly/ML, developed at the University of Cambridge by David Matthews across the same period, provided a second implementation that prioritized persistence of compiled code across sessions.
Standard ML consolidated the Hindley-Milner type system that the previous article covered with an ML module system that Milner had begun to develop in the late nineteen seventies. The module system supported parameterized modules, called functors, which took modules as arguments and returned modules as results. The design was substantially different from the module systems of Modula-2 and Ada that were in industrial use at the same time, which did not support functor abstractions. The ML module system would influence Rust, Scala, and subsequent language designs that support module-level parameterization.
David Turner at the University of Kent at Canterbury had developed KRC, short for the Kent Recursive Calculator, in the late nineteen seventies as a lazy functional programming language for teaching purposes. KRC’s successor Miranda, which Turner developed starting in nineteen eighty-three and released commercially in nineteen eighty-five, carried the lazy functional programming approach into a form that was substantially more usable than KRC.
Miranda was a pure, non-strict, polymorphically typed functional programming language whose type system was Hindley-Milner with several extensions. Non-strict evaluation, also called lazy evaluation, meant that a function argument was not evaluated until its value was needed by the function body. The evaluation strategy allowed programs to work with data structures that were notionally infinite, because only the portion that was actually needed would be computed. The strategy also provided a specific form of modularity, namely the separation of producers of a data stream from consumers of it, which imperative languages had difficulty expressing cleanly.
Miranda was substantially influential on the programming languages community of the late nineteen eighties. Multiple research groups were developing lazy functional languages in the same period, including Simon Peyton Jones’s Ponder at Cambridge and Philip Wadler’s Orwell at Oxford. The proliferation of similar-but-incompatible languages became a problem for the research community. In nineteen eighty-seven, at the Functional Programming and Computer Architecture conference in Portland, Oregon, a group including Peyton Jones, Wadler, Paul Hudak, John Hughes, and others resolved to design a single common lazy functional language that the research community could share. The design effort resulted in Haskell, whose first version appeared in nineteen ninety. The article after this develops the Haskell design work in its nineteen nineties mature form.
Category theory had entered the semantics literature in the late nineteen sixties through the work of Dana Scott and others on Cartesian closed categories as models of the typed lambda calculus. The nineteen eighties saw category-theoretic techniques cross from a specialty of denotational semanticists into a working tool of programming language design.
John Reynolds’s paper
Types,
Abstraction and Parametric Polymorphism,
delivered at
the ninth International Federation for Information Processing
World Computer Congress
in Paris
from September nineteenth
through
September twenty-third
of nineteen eighty-three,
introduced
the parametricity theorem
for
System F.
The theorem
established that
a polymorphic function
of type
∀α. τ
in System F
must behave
uniformly
across all instantiations
of
its type parameter.
The theorem
gave
a mathematical account
of
what
programmers
had known
informally,
namely that
a function
whose type
does not mention
a specific type
cannot depend
on
its structure.
A specific consequence
is that
any polymorphic list-to-list function
f : ∀α. [α] → [α]
satisfies
map g . f = f . map g
for every function g,
because
f cannot inspect
the list elements
and must therefore
commute
with
element-wise transformation.
The theorem
had
practical consequences
that
Philip Wadler
would later
develop
into
the theorems-for-free program
under
the name
free theorems.
The nineteen eighty-six book Introduction to Higher-Order Categorical Logic by Joachim Lambek and Philip Scott, published by Cambridge University Press, consolidated the categorical logic program into a textbook. The book established the correspondences between typed lambda calculi and various classes of categories, including the correspondence between the simply typed lambda calculus and Cartesian closed categories, and the correspondence between higher-order intuitionistic logic and toposes. The book made categorical logic accessible to researchers who did not have direct category theory training, and its treatment became the standard reference for categorical semantics in the following decades.
Category theory
also
became
practical
through
the monad
as
a structural pattern
for
denotational semantics
of
computational effects.
Eugenio Moggi’s
nineteen eighty-nine paper
Computational Lambda-Calculus and Monads,
delivered at
the Logic in Computer Science conference,
introduced
the categorical monad
as
a semantic device
for
modeling
effects
in
a call-by-value setting.
A monad M
supplied
two operations,
return : α → M α
that injects
a pure value
into the monad,
and
bind : M α → (α → M β) → M β
that sequences
a computation
in the monad
with
a function
producing
a further computation.
Moggi’s paper
established that
different kinds of effects,
including
state,
input-output,
exceptions,
and nondeterminism,
could be
uniformly modeled
by
different monads
in
the same categorical framework.
The paper
became
the founding paper
of
the monadic effects tradition,
which
Philip Wadler
and
Simon Peyton Jones
would
develop
into
practical language features
of Haskell
in
the nineteen nineties.
John Lucassen
and
David Gifford
at
the Massachusetts Institute of Technology
introduced
polymorphic effect systems
in
their nineteen eighty-eight paper
Polymorphic Effect Systems,
delivered at
the fifteenth Symposium
on Principles of Programming Languages.
The paper
extended
the Hindley-Milner type discipline
with
a kinded type system
that
carried
three base kinds,
namely
types,
which described
the value
an expression
might return,
effects,
which described
the side effects
the expression
might cause,
and
regions,
which described
the areas of the store
where
side effects
might occur.
Expressions
could be abstracted
over
any kind of description variable,
which
gave
the system
polymorphism
over
types,
effects,
and regions
uniformly.
An effect judgment
took the form
Γ ⊢ e : τ ! ε,
where
the ! separates
the expression’s type τ
from
its effect ε,
a notation
that
later effect-system papers
would
uniformly adopt.
The effect kind was substantially the innovation of the paper. An effect was a set of atomic effects, each of which described a specific operation that a program might perform, such as reading from a specific memory region or writing to a specific input-output channel. An effect discipline allowed the compiler to statically determine what operations a program might perform, which enabled compiler optimizations that depended on the absence of specific effects, including parallelization of expressions that had disjoint effects.
The FX programming language, also from the Gifford group at MIT, was the experimental implementation of the effect system. The FX-87 report by Gifford, Jouvelot, Lucassen, and Sheldon, published in nineteen eighty-seven, described the language and its compilation strategy. Subsequent work on effect systems extended the Lucassen-Gifford approach in several directions, including the algebraic effects that would emerge in the twenty tens, which the article on that decade covers.
The nineteen eighty-eight paper and the FX experiment established effect systems as a research program distinct from the type-inference program that Hindley-Milner had launched. The two programs have interacted continuously since, with effect systems often being formulated as extensions of Hindley-Milner that add effect kinds to the existing type kind.
Object-oriented programming, which Simula sixty-seven had established in the nineteen sixties, matured in the nineteen eighties through three developments.
The first development was the publication of Smalltalk-80. The Xerox Palo Alto Research Center had developed Smalltalk as a series of experimental languages across the nineteen seventies, with Smalltalk-72, Smalltalk-74, Smalltalk-76, and Smalltalk-78 as successive research prototypes. Smalltalk-80 was the version that Xerox PARC released publicly in nineteen eighty. The definitive presentation of the language was Adele Goldberg and David Robson’s nineteen eighty-three book Smalltalk-80, The Language and Its Implementation, published by Addison-Wesley as the first of the Smalltalk-80 book series in what came to be called the blue book.
Smalltalk-80 introduced several concepts that became standard vocabulary for object-oriented programming, including the metaclass, which was a class whose instances were themselves classes, the reflective protocol, which allowed a running program to inspect and modify its own structure, and the message-passing call convention, which treated every operation as sending a message to an object. The book also described the Smalltalk-80 development environment, which had been the first integrated development environment that supported class browsing, inspector-based debugging, and live-code editing. Substantially every integrated development environment of the following decades descends from the Smalltalk-80 design.
The second development was the emergence of C++. Bjarne Stroustrup at AT&T Bell Laboratories had begun developing what he called C with Classes in nineteen seventy-nine. The system extended the C language with Simula-style classes and member functions, and had gained enough internal AT&T users that Stroustrup renamed it C++ in nineteen eighty-three. The first edition of Stroustrup’s book The C++ Programming Language appeared from Addison-Wesley in nineteen eighty-five. C++ took the object-oriented design that Smalltalk-80 had made canonical and adapted it to the systems-programming and industrial-application-programming contexts where C was already used, which Smalltalk-80’s dynamic-typing and image-based-development approach did not fit.
The third development was the founding of OOPSLA. Adele Goldberg, Tom Love, David Smith, and Allen Wirfs-Brock established the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications in nineteen eighty-five. The first OOPSLA was held at the Marriott Hotel in Portland, Oregon, in November of nineteen eighty-six, with approximately six hundred attendees and fifty papers. The conference became the primary venue for object-oriented programming research and the industrial adoption of object-oriented techniques that the decade would produce.
The nineteen eighties supplied six things that the following decades consumed.
First, a working Prolog implementation technology, namely the Warren Abstract Machine, that every subsequent performant Prolog implementation either targets directly or extends.
Second, Standard ML as a working research language with a formal type system, a module system, and two reference implementations, whose Definition would appear in the following decade and which would become the standard functional-language research vehicle for the following two decades.
Third, Haskell as a common design goal for the lazy functional programming community, whose implementation would appear in the following decade.
Fourth, category theory as a working tool of programming language design, through Reynolds parametricity, the Lambek-Scott book, and Moggi’s monads.
Fifth, effect systems as a distinct research program, through Lucassen-Gifford polymorphic effect systems and the FX language.
Sixth, object-oriented programming as a mature discipline, through Smalltalk-80, C++, and OOPSLA.
The next article, A212, covers the nineteen nineties.
The nineteen eighties took the theoretical results of the nineteen seventies and turned each of them into a working research program. Hindley-Milner became Standard ML. Denotational semantics became categorical semantics. Simula sixty-seven’s classes became Smalltalk-80, C++, and OOPSLA. Prolog became the Warren Abstract Machine. Effect systems became a distinct research direction. The lazy functional programming community converged on Haskell as its shared design goal.
The next article, A212, covers the nineteen nineties.
The theoretical side of the nineteen seventies took the mathematical foundations that the nineteen sixties had established and produced a small number of specific technical results that the following four decades would develop. Hindley’s principal type theorem and its independent rediscovery by Milner gave the discipline its first practical type inference algorithm. Milner’s Logic for Computable Functions gave the discipline its first interactive theorem prover and, as a side effect, the first ML. Per Martin-Löf’s intuitionistic type theory extended the type-theoretic foundations to dependent types and supplied a foundation for constructive mathematics that subsequent proof assistants would implement. Dorothy Denning’s lattice model of information flow supplied the mathematical structure that production information-flow-control languages of the twenty tens and twenty twenties would eventually adopt. William Howard’s manuscript on the correspondence between formulas and types made explicit a specific structural analogy that would organize type theory for the rest of the century. The ACM Symposium on Principles of Programming Languages founded in October of the same decade became the primary venue in which all of this work was published.
The companion article covers the pragmatic side of the same decade. The reader should treat the two articles as a single treatment in two parts.
The first ACM Symposium on Principles of Programming Languages was held in Boston, Massachusetts, in October of nineteen seventy-three. Patrick C. Fischer and Jeffrey D. Ullman edited the proceedings. The symposium was a joint venture of the ACM Special Interest Group on Programming Languages and the ACM Special Interest Group on Algorithms and Computation Theory.
The founding of a dedicated symposium for theoretical work on programming languages was a substantive editorial statement. It asserted that programming language theory was a distinct research discipline with its own methods and its own publication venues, separate from compiler construction, which already had the SIGPLAN Symposium on Compiler Construction that became PLDI in the nineteen eighties, and separate from software engineering, which would develop its own venues across the following decade.
The symposium’s first several years established the format that the venue continues to use. Papers are rigorously refereed against a bar that emphasizes technical novelty and mathematical precision. The symposium did not publish tool papers or experience reports in its first years, and the emphasis on theoretical content remains its distinguishing characteristic against adjacent venues.
The founding of the symposium supplied the discipline with a permanent record of its work. Every article in the remainder of this series that names a specific technical result from the nineteen seventies onward either was published in the proceedings of the symposium or was published in a venue that the symposium established as a peer standard.
J. Roger Hindley published The Principal Type-Scheme of an Object in Combinatory Logic in the Transactions of the American Mathematical Society, volume one hundred forty-six, pages twenty-nine through sixty, in nineteen sixty-nine. The paper proved a specific result about combinatory logic that would become the foundation of type inference in statically typed functional programming languages.
The result
concerns
what happens
when
a term of combinatory logic
is asked
what type it has.
A term
may have
many types.
The identity combinator,
for example,
maps
any type
to itself,
so it has
the type
Nat → Nat,
the type
Bool → Bool,
the type
(Nat → Nat) → (Nat → Nat),
and infinitely many others.
Hindley’s theorem
established that
these types
are not
unrelated.
They are
all instances
of
a single most general type,
written
∀α. α → α,
which
the theorem
called
the principal type-scheme.
The principal type-scheme
is unique
up to renaming
of its bound variables.
Every other type
that a term admits
is
an instance of the principal type-scheme
obtained by
substituting concrete types
for
the bound variables.
The theorem gave an algorithm for computing the principal type-scheme from the term. The algorithm performs unification of type expressions against a set of constraints derived from the term’s structure. Robinson’s nineteen sixty-five paper A Machine-Oriented Logic Based on the Resolution Principle had supplied the unification algorithm. Hindley applied it to the type-inference problem.
The paper was not widely read in the programming languages community at the time of its publication. Its content became influential through Robin Milner’s independent rediscovery of the same result almost a decade later.
Robin Milner had joined the Stanford University Artificial Intelligence Laboratory in the late nineteen sixties. His nineteen seventy-two technical report, Logic for Computable Functions, Description of a Machine Implementation, distributed as Stanford Artificial Intelligence Laboratory Memo AIM-169, introduced the Logic for Computable Functions system, which came to be called Edinburgh LCF after Milner moved to the University of Edinburgh in nineteen seventy-three and continued the work there.
The Logic for Computable Functions was a formal logic that Dana Scott had proposed in an unpublished nineteen sixty-nine note. Scott’s logic extended first-order predicate calculus with constructions for computable partial functions over recursively defined domains. The logic was intended as a mathematical foundation for reasoning about the meanings of programs in the Scott-Strachey denotational-semantic style that the companion article develops. Milner’s LCF system was the first mechanical implementation of Scott’s logic.
The system allowed a user to interactively generate formal proofs about recursively defined functions. Proofs were constructed by applying inference rules of the logic to previously proved theorems. The system maintained a data structure representing the current goal and the accumulated proof, and provided commands for extending the proof by one inference step at a time.
The system’s principal innovation was the tactic mechanism. A tactic was a program that transformed a goal into a list of subgoals whose proofs would together suffice to prove the original goal. Tactics could be combined using tacticals, which were higher-order operations on tactics that allowed complex proof strategies to be constructed from simple ones. The tactic mechanism required a programming language in which tactics could be written. That language was ML.
ML, which stood for Meta Language, was the language in which LCF tactics were written. Milner and his collaborators at Edinburgh designed the language across the mid nineteen seventies. The formal type-system foundations of the language appeared in a nineteen seventy-eight paper by Milner titled A Theory of Type Polymorphism in Programming in the Journal of Computer and System Sciences, volume seventeen, pages three hundred forty-eight through three hundred seventy-four. The paper independently rediscovered the Hindley principal type theorem and supplied a type-inference algorithm that came to be called Algorithm W. A complete description of the language appeared in the nineteen seventy-nine book Edinburgh LCF by Michael Gordon, Robin Milner, and Christopher Wadsworth, published by Springer.
Algorithm W takes a term without type annotations and computes its principal type-scheme. The algorithm proceeds by recursive descent on the term structure, generating type constraints at each application and each abstraction, and solving the constraints by unification at the end. The algorithm succeeds if the term is well-typed and fails if the term is not, and its output is the most general type that the term admits.
The Hindley-Milner type system,
which ML implements,
has
a specific technical property
that makes
type inference
practical.
The property
is
that
principal types exist
and can be computed
without
annotation.
A programmer
can write
fn x => x
in ML
and the compiler
determines that
the function
has type
∀α. α → α
without
any type declaration.
The property
distinguishes
Hindley-Milner
from
the more powerful System F,
in which
principal types
do not exist
in general
and
type inference
is undecidable.
The trade-off that Hindley-Milner accepts is that not every well-typed program can be expressed in its type system. Programs that require higher-rank polymorphism or existential types cannot be inferred by Algorithm W. Modern successors, including Haskell, provide type-annotation escape hatches that extend the inferable fragment to cover more expressive types at the cost of requiring annotations for the extended fragment.
Luis Damas, Milner’s doctoral student at Edinburgh, supplied the formal soundness proof of Algorithm W in a nineteen eighty-two joint paper with Milner at the Symposium on Principles of Programming Languages and in his nineteen eighty-five doctoral dissertation. The Damas-Milner soundness proof established that Algorithm W computes the principal type-scheme correctly and that principal types have the expected substitution property. The algorithm is now called Hindley-Damas-Milner or Damas-Milner in the formal-methods literature to acknowledge Damas’s contribution.
Per Martin-Löf delivered a lecture series in nineteen seventy-one that introduced a type theory intended as a foundation for constructive mathematics. The original nineteen seventy-one formulation was impredicative, meaning that it included a type of all types that could quantify over itself. Jean-Yves Girard proved that the impredicative formulation was inconsistent using a variant of the Burali-Forti paradox. Martin-Löf revised the theory in nineteen seventy-two to a predicative formulation that avoided self-reference by introducing a hierarchy of universes, each of which contained types of lower universes.
The predicative formulation
was
presented
at
the nineteen seventy-three Logic Colloquium
and
published
in nineteen seventy-five
in
the Logic Colloquium ‘73 proceedings
under the title
An Intuitionistic Theory of Types,
Predicative Part.
The theory
included
dependent types,
which
are
types
that depend
on
values.
The dependent function type,
written
Π (x : A). B(x),
is
the type of functions
that
take
a value x of type A
and return
a value
of type B(x),
where B(x)
is
a type
that depends
on x.
The dependent pair type,
written
Σ (x : A). B(x),
is
the type of pairs
whose first component
is
a value x of type A
and whose second component
is
a value
of type B(x).
Dependent types were a substantial extension of the simply typed lambda calculus that the foundations article described. The simply typed lambda calculus distinguishes values from types and treats them as separate levels. Martin-Löf’s type theory collapses the distinction. A type is a value that lives in a universe. A value that a function takes can be a type. The collapse allowed mathematical propositions to be expressed as types, and proofs of propositions to be expressed as values of the corresponding types.
Martin-Löf published the definitive presentation of the theory in his nineteen eighty-four book Intuitionistic Type Theory, based on notes by Giovanni Sambin from a lecture series in Padua. The book became the standard reference for the theory and the basis for the Agda, Coq, and Lean proof assistants of subsequent decades.
Haskell Curry
had noted
in
his nineteen fifty-eight book
Combinatory Logic
that
there was
a structural analogy
between
the types
of
combinators
and
the propositions
of
intuitionistic propositional logic.
The type of the K combinator,
namely
A → B → A,
was
the same
as
the axiom
A ⊃ (B ⊃ A)
of
intuitionistic propositional logic.
Curry’s observation
was
suggestive
but
not
formally developed.
William Howard formalized Curry’s observation into a full correspondence in a manuscript titled The Formulae-as-Types Notion of Construction, written in nineteen sixty-nine and circulated as a xeroxed copy among type theorists for the next decade. The manuscript was not published until nineteen eighty, when it appeared in the Festschrift volume To H. B. Curry, Essays on Combinatory Logic, Lambda Calculus and Formalism, edited by Jonathan Seldin and J. Roger Hindley.
Howard’s correspondence
established
a specific systematic connection.
Propositions
of intuitionistic propositional logic
correspond
to types
of the simply typed lambda calculus.
Proofs
of propositions
correspond
to terms
of the corresponding types.
Proof normalization
corresponds
to
beta reduction
of the corresponding term.
The correspondence
extends
to intuitionistic predicate logic
and
Martin-Löf’s dependent type theory
in
a natural way,
so that
universal quantification
∀x. P(x)
corresponds
to
the dependent function type
Π (x : A). B(x)
and
existential quantification
∃x. P(x)
corresponds
to
the dependent pair type
Σ (x : A). B(x).
The correspondence is the foundation of the modern proof-assistant program. A proof assistant that implements Martin-Löf-style dependent type theory, including Agda, Coq, Lean, and F-star, uses the correspondence to allow a user to construct a proof of a proposition by writing a term of the corresponding type. The type checker verifies that the term has the claimed type, which by the correspondence is the claim that the term proves the proposition. Type checking and proof checking are the same operation.
Dorothy Denning published A Lattice Model of Secure Information Flow in Communications of the ACM volume nineteen, pages two hundred thirty-six through two hundred forty-three, in May of nineteen seventy-six. The paper formalized the mathematical structure of information-flow constraints in a way that would lay dormant for close to two decades before production programming languages adopted it.
The paper’s central object
is
a lattice
(L, ≤, ⊕, ⊗),
where
L is a set of security classes,
≤ is a partial order on the security classes,
⊕ is the least upper bound operation,
and
⊗ is the greatest lower bound operation.
A program
respects
the lattice
if information
flowing from
a value
of security class x
to
a value
of security class y
requires
x ≤ y,
namely
that
the source class
is
at or below
the destination class
in the partial order.
The condition
prohibits
information
from flowing
upward
in the lattice
to
a class
that
does not
already
contain
that information.
The paper gave a specific example lattice for a two-level security system with classes public and private, in which public information can flow to private but private information cannot flow to public. The general lattice handles more complex classification schemes that distinguish between different secrecy categories and different integrity levels, each of which forms its own dimension in the lattice.
The paper also gave a static analysis that verifies whether a program respects the lattice. The analysis traces the information flow through assignments, conditionals, and loops, and computes for each value in the program a security class that represents the maximum classification of information that could have flowed into that value. The analysis rejects a program that requires an information flow that the lattice prohibits.
The paper was substantially ahead of the state of practical programming languages at the time of its publication. Production programming languages of the nineteen seventies and nineteen eighties did not carry information-flow types. The paper’s mathematical apparatus would begin to see practical use in the late nineteen nineties when Andrew Myers built JFlow at the Massachusetts Institute of Technology as his doctoral work and, subsequently, Jif at Cornell, both on the Denning foundation, and would reach production adoption in the twenty twenties in languages such as Keleusma that carry information-flow labels in the surface type system. The article after next in this series, A212, develops the nineteen nineties adoption. The article on the twenty twenties, A215, develops the production adoption.
The theoretical side of the nineteen seventies supplied five things that the following decades consumed.
First, type inference as a practical technique, through the Hindley-Milner algorithm. Every statically typed functional language after ML either uses Hindley-Milner directly or extends it with annotation escape hatches for more expressive types.
Second, the tactic mechanism for interactive theorem proving, through LCF. Every subsequent interactive theorem prover, including HOL, Isabelle, Coq, Agda, Lean, and F-star, uses tactic-based proof construction in the LCF tradition.
Third, dependent types as a foundation for proof assistants, through Martin-Löf’s theory. Every modern proof assistant that supports mathematical propositions as types implements some fragment of Martin-Löf’s theory.
Fourth, the Curry-Howard correspondence as the organizing principle of the proof-assistant program. The identification of proofs with programs allowed the type-checker to serve as the proof-checker, which made the following decades of mechanized mathematics practical.
Fifth, the information-flow lattice as the mathematical foundation for security-typed programming languages. The Denning apparatus lay dormant for close to two decades before practical uptake began.
The next article, A211, covers the nineteen eighties.
The theoretical side of the nineteen seventies established five research programs that the following decades would develop. Type inference became Hindley-Milner and its extensions. Interactive theorem proving became the LCF tradition of tactics. Dependent types became Martin-Löf’s theory and its implementations. The correspondence between formulas and types became the organizing principle of proof assistants. The information-flow lattice became the foundation that production information-flow languages would eventually adopt.
None of these were production techniques in the nineteen seventies. All of them were established results by the end of the decade, and each of them would develop into a working discipline over the following forty years.
The next article, A211, covers the nineteen eighties.
The nineteen seventies were dense enough to require two articles. This first article covers the pragmatic side of the decade, namely the consolidation of structured programming as a discipline, the maturation of the denotational semantics program that Scott and Strachey had begun in the previous decade, the development of production programming languages that established the reference points against which every subsequent language design would be measured, and John Backus’s public argument that the industrial mainstream was on the wrong path. The companion article, A210, covers the theoretical side of the same decade, namely Hindley-Milner type inference, Robin Milner’s Logic for Computable Functions and the first ML, Per Martin-Löf’s type theory, Dorothy Denning’s information-flow lattice, and the founding of the ACM Symposium on Principles of Programming Languages in nineteen seventy-three.
The division between the pragmatic and the theoretical is editorial. The two sides interacted continuously. Robin Milner’s LCF was a pragmatic tool built on Dana Scott’s theoretical work. Niklaus Wirth’s Pascal drew on the same ALGOL sixty tradition that generated denotational semantics. The reader should treat the two articles as a single treatment in two parts.
Ole-Johan Dahl, Edsger Dijkstra, and C. A. R. Hoare published the book Structured Programming through Academic Press in nineteen seventy-two. The book consolidated the arguments that had accumulated across the previous decade into a single treatment. Dijkstra’s contribution, Notes on Structured Programming, laid out a programming discipline whose central practice was the stepwise refinement of a problem statement into an implementation. Hoare’s contribution, Notes on Data Structuring, extended the same discipline to the design of data representations. Dahl’s contribution, Hierarchical Program Structures, tied the discipline to the class-based structure that Simula sixty-seven had introduced.
Niklaus Wirth had already published, in April nineteen seventy-one in Communications of the ACM, the paper Program Development by Stepwise Refinement, which presented a worked example of the discipline applied to an eight-queens problem. Wirth’s paper made the practice concrete by walking through the successive refinements of an informal specification into a program that could be executed. The paper became the standard classroom introduction to structured programming for the following two decades.
The combined effect of the nineteen seventy-two book and Wirth’s nineteen seventy-one paper was to move structured programming from a position that required argument to a position that required justification only in its absence. By the middle of the decade the goto statement had become a construct whose use called for explicit defense rather than occasional caution. The transition was substantially complete by the end of the decade in new language design, though existing production languages that included the goto statement continued to carry it for backward compatibility.
Dana Scott and Christopher Strachey’s nineteen seventy-one Oxford technical monograph, Toward a Mathematical Semantics for Computer Languages, launched what became known as denotational semantics in the following years. The monograph proposed that the meaning of a program should be a mathematical object in a specific domain, namely a partial order of computational elements whose limits correspond to the results of nonterminating or partially defined computations. Scott’s domain theory supplied the mathematical infrastructure.
The nineteen seventies saw the denotational program expand in three directions.
The first direction was the treatment of specific language features. Denotational descriptions of assignment, of higher-order functions, of control operators such as continuations, and of nondeterminism were developed by Scott, Strachey, Peter Mosses, and others at Oxford’s Programming Research Group. Continuations in the sense that later work would use the term were introduced by Christopher Strachey and Christopher Wadsworth in a nineteen seventy-four Oxford PRG memo titled Continuations, a Mathematical Semantics for Handling Full Jumps. The memo gave a mathematical account of nonlocal control transfer that would later underwrite first-class continuations in Scheme and delimited continuations in modern functional languages.
The second direction
was
the elaboration
of domain theory itself.
Scott’s nineteen seventy-six paper
Data Types as Lattices
in
the SIAM Journal on Computing
consolidated
the mathematical treatment
of the domain construction
into
a form
that other researchers
could apply directly.
The paper
introduced
what became known
as
D-infinity,
the reflexive domain
that satisfies
the equation
D ≅ D → D,
namely
that a domain is isomorphic
to
its own function space,
which
underwrites
the treatment
of the untyped lambda calculus
as
a denotational object.
The third direction was the exposition of the denotational program in a form that could be taught to graduate students. Joseph Stoy’s nineteen seventy-seven book Denotational Semantics, subtitled The Scott-Strachey Approach to Programming Language Theory, published by the MIT Press, gave the discipline its first textbook. Stoy had been a research fellow at the Oxford PRG. His book made the Scott-Strachey approach accessible to readers who did not have direct access to the Oxford technical monograph series.
Edsger Dijkstra had continued the research program that his nineteen sixty-eight Go To letter had opened. His nineteen seventy-five paper Guarded Commands, Nondeterminacy and Formal Derivation of Programs, published in Communications of the ACM volume eighteen, issue eight, introduced two related contributions.
The first was
a small programming language
called
the guarded command language,
whose central control construct
was
a nondeterministic choice
among
guarded alternatives.
An alternative
consisted of
a boolean guard
and
a statement.
The construct
executed
by
choosing
any
alternative
whose guard evaluated to true
and
executing
its statement.
A construct
in which
no guard was true
either
aborted
or
did nothing,
depending on
which of the two guarded constructs,
if or do,
was in use.
The guarded command language
was
not intended
as
a production programming language.
It was
a notation
for
reasoning about
programs
whose control flow
had been abstracted
to
its essential structure.
The second contribution
was
the weakest precondition semantics.
For each statement S
in the guarded command language
and each postcondition Q,
the weakest precondition,
written wp(S, Q),
was
the weakest predicate
such that
if it held
before S executed
then Q
would hold
after S terminated.
The weakest precondition
was
defined
compositionally
by rules
that recursed
on
the structure
of the statement.
The rule for assignment
reads
wp(x := E, Q) = Q[E/x],
which mirrors
the Hoare assignment axiom
of the previous decade.
The rules together
provided
a mechanical procedure
for
computing
what a program required
of its input
to guarantee
that its output
would satisfy
a given specification.
Dijkstra’s nineteen seventy-six book, A Discipline of Programming, published by Prentice-Hall, developed the weakest precondition approach into a systematic method for constructing programs that were correct by construction. The method took a specification, represented as a precondition and postcondition pair, and derived the program that satisfied it by mechanical application of the weakest precondition rules in reverse. The book worked through a substantial catalog of programming problems using this method.
The Dijkstra approach and the Hoare axiomatic method of the previous decade are closely related. The Hoare method takes a program and a specification and proves that the program satisfies the specification. The Dijkstra method takes a specification and derives a program from it. The two directions correspond to verification and program derivation respectively. Both directions depend on the same weakest precondition apparatus. Modern program verifiers carry both directions as selectable modes.
Niklaus Wirth began work on Pascal at the Eidgenössische Technische Hochschule Zürich in nineteen sixty-eight. The language grew out of ALGOL-W, an ALGOL sixty successor that Wirth had proposed in the ALGOL sixty-eight design process and that had been developed as a working language at Stanford while Wirth was there. When Wirth returned to Zurich in nineteen sixty-eight, he began a new language design that would carry the ALGOL-W direction without the ALGOL sixty-eight complexity.
The first Pascal compiler became operational in early nineteen seventy. The initial attempt was written in FORTRAN and failed because the Pascal type system’s data-structure requirements could not be expressed cleanly in FORTRAN. The second attempt, by Urs Ammann, Edgar Marmier, and Rudolf Schild, was written in Pascal itself using a bootstrap compiler and succeeded. The compiler was a single-pass recursive-descent compiler whose performance was comparable to contemporary FORTRAN compilers on the same hardware. The technical report The Programming Language Pascal appeared in November nineteen seventy as Technical Report Number One of the Zurich computer science department. By nineteen seventy-two Pascal was in use in introductory programming courses.
Kathleen Jensen and Niklaus Wirth published the Pascal User Manual and Report through Springer in nineteen seventy-four. The book consolidated the language definition and gave the language its reference document for the following two decades. The Pascal-P portable compiler, developed at Zurich, generated p-code, a bytecode for a stack-based virtual machine, that could be interpreted on any target platform that ran the interpreter. The p-code approach made Pascal implementations straightforward to port and became the technique by which Pascal spread across academic and industrial installations.
Pascal was designed to be a small language that could be taught in a semester and understood in its entirety. It included records, enumerations, subranges, sets, and pointers, which together gave the programmer enough data-structuring apparatus to write non-trivial programs without appealing to external libraries. It excluded features whose semantics were considered problematic, including separate compilation and unrestricted pointer arithmetic.
The exclusions were the origin of Pascal’s principal criticism as an industrial language. Brian Kernighan published a nineteen eighty-one paper titled Why Pascal Is Not My Favorite Programming Language, which catalogued the practical difficulties that the exclusions imposed on substantial software development. The criticism was substantive. Pascal had been designed for teaching rather than for industrial use, and its use as an industrial language required extensions whose incompatibility across implementations undid much of the portability that the p-code approach had provided. The Modula and Modula-2 languages, covered below, were Wirth’s response to the industrial-use case.
Dennis Ritchie developed what became C at Bell Laboratories between nineteen seventy-two and nineteen seventy-three. C grew out of Ken Thompson’s B language of nineteen sixty-nine, which in turn had grown out of Martin Richards’s BCPL of nineteen sixty-seven. The transition from B to C happened as Bell Labs migrated its UNIX operating system from the PDP-7 to the PDP-11 minicomputer. The shortcomings of B became apparent on the newer hardware, and Ritchie extended the language over the following year to give it data types and the structural apparatus that B had lacked.
Ken Thompson rewrote the UNIX kernel in C in nineteen seventy-two. The rewrite was substantial evidence for the position that a systems programming language could be substantially higher-level than assembly without paying an unacceptable cost. The rewrite also established that an operating system that one wanted to port to a new hardware architecture could be ported by writing a C compiler for the new architecture rather than by rewriting the operating system. Every subsequent UNIX-family operating system that has been ported to a new architecture has relied on this technique.
Brian Kernighan and Dennis Ritchie published The C Programming Language through Prentice Hall in February nineteen seventy-eight. The book became known as K&R after the initials of the authors. It served as the reference document for the language until the American National Standards Institute published the C 89 standard in nineteen eighty-nine. The pre-standard version of the language that K&R described is sometimes called K&R C to distinguish it from the subsequent standardized versions.
C’s design made different trade-offs than Pascal’s. It included separate compilation through header files, pointer arithmetic, and a preprocessor that supported conditional compilation and macro definition. It excluded the array-bounds checking and subrange types that Pascal included. The trade-offs made C directly usable for systems programming and for the writing of compilers, operating systems, and device drivers. The trade-offs also made C substantially more error-prone than Pascal in application programming, which became the substance of the systems-versus-application-language debate that subsequent decades would carry forward.
Alain Colmerauer and his team at the Université d’Aix-Marseille implemented the first version of Prolog in the summer of nineteen seventy-two. The name Prolog was coined by Philippe Roussel as an abbreviation of Programmation en Logique. The language was the first practical logic programming language.
The discovery
that
a specific fragment of first-order logic,
namely
Horn clauses
of the form
H :- B1, B2, ..., Bn,
where H is a head atom
and each Bi is a body atom
that must hold
for H to hold,
could be
executed
by
a resolution theorem prover
in
a way that
constitutes
a computational procedure
was
the result
of
a collaboration
between
Colmerauer at Marseille
and
Robert Kowalski at Edinburgh.
Kowalski’s nineteen seventy-four paper
Predicate Logic as Programming Language,
delivered at
the International Federation for Information Processing Congress
in Stockholm,
formalized
the theoretical basis.
Colmerauer’s Marseille group
had built
the practical implementation
in the interim.
Prolog executes a Horn clause program by attempting to prove a goal using SLD resolution, a specific strategy that processes clauses in source order and resolves subgoals depth-first from left to right. The strategy is not complete in the theorem-proving sense, because depth-first search can enter an infinite computation where a breadth-first search would succeed. The trade-off is efficiency. A Prolog implementation runs comparably to an imperative language implementation of the same problem when the problem matches the depth-first search pattern. Extending Prolog to handle programs that require a different search strategy became the substance of later work on constraint logic programming and other logic programming paradigms.
Prolog introduced the discipline of declarative programming as a working style, distinct from the imperative style of C and Pascal and from the functional style that Backus’s Turing Award lecture would argue for. The three styles have coexisted in the discipline since, with individual production languages selecting among them according to their intended use.
Per Brinch Hansen developed Concurrent Pascal at the California Institute of Technology in nineteen seventy-four and nineteen seventy-five. The language extended Pascal with the monitor construct, which Brinch Hansen had introduced in a nineteen seventy-two paper and which C. A. R. Hoare had independently formalized in a nineteen seventy-four paper titled Monitors, An Operating System Structuring Concept. A monitor is a module that encapsulates shared data together with the operations that access it, and that enforces mutual exclusion by allowing at most one operation to execute at any given time.
Concurrent Pascal was implemented on the PDP-11/45 by January nineteen seventy-five. The implementation demonstrated that a language whose concurrency primitives were tied to the monitor construct could be implemented efficiently on a single-processor system and that the resulting programs were substantially easier to reason about than programs that used lower-level synchronization primitives. The Solo operating system, written in Concurrent Pascal at Caltech, was the first published operating system written in a high-level concurrent programming language.
Niklaus Wirth developed Modula at Zurich across nineteen seventy-five through nineteen seventy-seven, publishing Modula, A Language for Modular Multiprogramming in Software: Practice and Experience in nineteen seventy-seven, as a response to the industrial-use criticism of Pascal. Modula added separate compilation through modules, which grouped related declarations and provided an interface that other modules could import. The module facility resolved Pascal’s principal industrial deficiency. The subsequent Modula-2, published by Wirth in nineteen eighty, consolidated the module design into what became the primary Wirth language of the nineteen eighties.
John Backus received the nineteen seventy-seven ACM Turing Award at the ACM Annual Conference in Seattle on October seventeenth nineteen seventy-seven. His Turing Award lecture, titled Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs, was published in Communications of the ACM in August nineteen seventy-eight. The lecture was the most influential critique of the industrial mainstream delivered in the decade.
Backus’s argument had two parts. The first part diagnosed what Backus called the von Neumann style of programming as the source of the difficulty of reasoning about industrial programs. The style was characterized by the assignment statement, which Backus called the von Neumann bottleneck, because every state change in a program had to pass through a single-slot pipeline of sequential assignments. The style also required the programmer to think in word-at-a-time terms rather than in whole-computation terms. The style, Backus argued, did not scale to the size of programs that industrial software was increasingly asked to be.
The second part of the argument proposed an alternative, namely a functional programming style in which programs were composed by combining smaller programs using a small set of combining forms. Backus’s specific proposal was a language called FP, whose programs were compositions of primitive functions by functional forms such as composition, condition, insert, and apply-to-all. FP was not intended as a production language but as a demonstration that a functional style could be made formal in a way that supported algebraic reasoning about whole programs. The lecture’s title called this the algebra of programs.
The lecture was influential substantially beyond its specific technical proposal. Its central diagnosis, that the assignment statement was the source of the industrial mainstream’s difficulty, became the founding argument for the functional programming research program of the following two decades. Standard ML, Miranda, Haskell, and every subsequent statically typed functional language descend from the position that Backus’s lecture articulated. The Turing Award recipient who had defined the FORTRAN era argued that the FORTRAN era was the wrong era. The subsequent decades would develop the alternative.
The pragmatic side of the nineteen seventies supplied five things that the following decades consumed.
First, structured programming as a settled discipline that new language designs took as a starting point rather than as a position requiring defense.
Second, denotational semantics as a mature mathematical framework for specifying the meaning of programming languages in a form that other researchers could apply.
Third, Pascal and C as reference points for subsequent language design. Every subsequent statically typed procedural language either extends one of these or is defined in opposition to one of these.
Fourth, Prolog as the first practical demonstration that declarative programming was a viable working style alongside the imperative and functional styles.
Fifth, the Backus critique as the founding argument for the functional programming research program.
The next article, A210, covers the theoretical developments of the same decade that the pragmatic side depended on.
The pragmatic side of the nineteen seventies took the questions that the nineteen sixties had made sharp and turned them into working tools. Structured programming became a discipline. Denotational semantics became a research program. Pascal and C became the reference points against which every subsequent procedural language would be measured. Prolog demonstrated that declarative programming was practical. Backus’s lecture articulated what the following decades would develop.
The next article, A210, covers the theoretical side of the same decade.
The nineteen sixties took the foundations that the previous article covered and turned them into a research discipline. The founding papers of the nineteen thirties had established that computation was a mathematically respectable subject. The practical demonstrations of the nineteen fifties had established that programming languages could be more abstract than the machines that ran them without ruinous cost. The nineteen sixties took both propositions as given and asked what kind of programming languages one should design, what kind of proofs one should carry about them, and what kind of mathematical objects their meanings should be.
The decade produced several papers that later work takes for granted. Peter Landin recast programming in terms of lambda calculus and gave the discipline its first abstract machine. Christopher Strachey began the mathematical semantics program that would become denotational semantics under Dana Scott in the following decade. Ole-Johan Dahl and Kristen Nygaard introduced classes and inheritance in Simula I and Simula sixty-seven, originating what became known as object-oriented programming. C. A. R. Hoare introduced the axiomatic method for program proof. Edsger Dijkstra argued that structured programming was a discipline rather than a preference. John McCarthy argued that a mathematical theory of computation was possible. The design of ALGOL sixty-eight consolidated much of the surface-language work of the decade and, in doing so, generated the design-by-committee controversy that would shape the language committees of the following decades.
This article walks the developments in the order they appeared, because the order in which the papers appeared is the order in which each depended on the last.
The LISP language described in John McCarthy’s April nineteen sixty paper went from a mathematical notation to a working implementation lineage across the first years of the decade. The LISP 1.5 Programmer’s Manual, prepared by McCarthy with Michael Levin, Paul Abrahams, Daniel Edwards, Timothy Hart, and others, appeared in nineteen sixty-two from the Massachusetts Institute of Technology Press. The manual consolidated the language into a form that other implementations could target without diverging.
The nineteen sixty-two manual
documented
several features
that became standard
in later LISP dialects.
The condition expression
called cond
handled multi-way branching
in a functional form.
The property list
attached
arbitrary key-value data
to a symbol.
The apply function
took a function
and a list of arguments
and evaluated the application,
making
the identification of program with data
usable from within a program.
The manual
also documented
the two-level LISP language,
a distinction
between
the surface syntax
that programmers write
and
the internal syntax
that the interpreter operates on.
The surface syntax
is
the tree-structured form
of function names
and arguments.
The internal syntax
is
S-expressions,
namely
lists whose elements
are atoms
or other lists.
The two-level structure
became the basis
for LISP macros
and for
the metacircular evaluator.
MacLisp, developed at the Massachusetts Institute of Technology starting in nineteen sixty-six, carried the LISP tradition forward into a form that supported substantially larger programs. MacLisp was the implementation on which the Macsyma symbolic algebra system was built. Other implementations diverged from the LISP 1.5 basis in the same period, producing Interlisp at Bolt, Beranek, and Newman and Stanford, and Standard Lisp at the University of Utah. The subsequent Scheme and Common Lisp efforts of the following two decades would attempt to reunify these branches.
Kristen Nygaard and Ole-Johan Dahl began development of Simula at the Norwegian Computing Center in Oslo in nineteen sixty-one. Simula I was designed as a special-purpose language for discrete-event simulation. The main design concepts were settled by May nineteen sixty-two. The first Simula I compiler was implemented on the Universal Automatic Computer 1107, which the Norwegian Computing Center had acquired at a discount under a contract with Univac that included the implementation work. The first prototype of the compiler ran in December nineteen sixty-four and the Simula I system became fully operational in January nineteen sixty-five. The Simula I manual appeared in May.
Simula I extended ALGOL sixty with the notion of a class, which packaged together a data structure and the procedures that operate on it. Class instances, called objects, could be created dynamically and referenced through pointer values. The language also introduced coroutines, which allowed a suspended computation to resume where it left off. Coroutines were the mechanism by which the simulation model represented multiple concurrent processes without operating-system-level parallelism.
Simula sixty-seven extended the class mechanism into what would be recognized as object-oriented programming. Dahl and Nygaard presented the paper Class and Subclass Declarations at the International Federation for Information Processing Working Conference on Simulation Languages in Oslo in May nineteen sixty-seven. The paper introduced subclass declaration, virtual procedures, and inheritance, which allowed a class to specialize the behavior of a parent class while preserving its interface. The Simula sixty-seven language also included a discrete-event simulation library and automatic memory management through garbage collection.
Simula was not widely used as an implementation language outside its simulation domain, but its concepts became the direct ancestors of Smalltalk, C++, Java, and every subsequent object-oriented language. Alan Kay, who developed Smalltalk at Xerox PARC in the nineteen seventies, credited Simula explicitly as the source of Smalltalk’s object model. Bjarne Stroustrup credited Simula sixty-seven as the direct model for the class mechanism in C with Classes, which became C++. Dahl and Nygaard received the two thousand one ACM Turing Award, announced in February two thousand two, for ideas fundamental to the emergence of object-oriented programming.
Peter Landin published three papers in the mid nineteen sixties that reshaped how programming language theory understood what a programming language is. The papers identified lambda calculus as the underlying mathematical structure of the surface languages that had begun to proliferate, introduced the first abstract machine for a functional language, and framed the design space of programming languages as a small number of decisions made against a common substrate.
The first paper, The Mechanical Evaluation of Expressions, appeared in The Computer Journal, volume six, issue four, in January nineteen sixty-four. The paper introduced the SECD machine, which is the first abstract machine for a functional programming language. The name SECD stands for Stack, Environment, Control, and Dump, which are the four components of the machine’s state. The stack holds intermediate values in an expression’s evaluation. The environment maps variable names to their bound values. The control carries the sequence of operations still to be performed. The dump holds suspended stack, environment, and control triples from function calls that have not yet returned.
The SECD machine gave lambda calculus a concrete operational reading. A lambda expression could be compiled to a sequence of SECD instructions and then executed on the machine. The compilation and execution together provided what present-day terminology would call an operational semantics for the lambda calculus. The SECD picture became the standard operational model for functional programming languages for the following two decades.
The second paper, A Correspondence Between ALGOL 60 and Church’s Lambda-Notation, appeared in Communications of the ACM in two parts across February and March nineteen sixty-five. The paper showed that ALGOL sixty’s call-by-value, call-by-name, and block-structure features could be systematically translated into lambda calculus. The translation made the mathematical content of ALGOL sixty explicit and provided a technique for reasoning about ALGOL sixty programs using the reduction rules of the lambda calculus. The correspondence was the first in a lineage of surface-language-to-lambda-calculus embeddings that includes the modern intermediate representations used by functional-language compilers.
The third paper, The Next 700 Programming Languages, appeared in Communications of the ACM, volume nine, issue three, in March nineteen sixty-six. The paper described a language called ISWIM, whose name stands for If You See What I Mean. ISWIM was a family of languages rather than a single language. It provided a common substrate, namely lambda calculus with a small set of syntactic conveniences, and allowed individual languages to be specified by supplying a set of primitives. The paper was a manifesto for the position that programming language design was a matter of choosing primitives against a fixed substrate.
ISWIM also introduced the off-side rule, which uses indentation to delimit syntactic scope. The off-side rule influenced Miranda, Haskell, Python, and several other later languages. The paper also coined the term syntactic sugar, which described a language feature that adds no expressive power over the underlying substrate but that improves readability. Both terms became standard vocabulary in the discipline.
John McCarthy’s paper A Basis for a Mathematical Theory of Computation, first delivered in preliminary form in nineteen sixty-one at the Western Joint Computer Conference in Los Angeles and published in expanded form in nineteen sixty-three in the volume Computer Programming and Formal Systems, edited by P. Braffort and D. Hirschberg for North-Holland, argued that a mathematical theory of computation was possible and that its central objects should be programs and their meanings, not merely computable functions in the abstract.
The paper introduced several ideas that later work would develop. It proposed that programming languages should have a formal mathematical semantics independent of any particular implementation. It argued that the correctness of a program should be provable by mathematical reasoning rather than established only by testing. It introduced the notion of proving properties of programs by induction on the recursive structure of the definitions. It identified recursion induction as a proof technique specialized to the domain of recursive definitions.
McCarthy’s paper was influential less for the specific technical apparatus it developed than for the research program it proposed. That program, which asked what a program means mathematically and how one proves properties of programs, became the central research program of programming language theory in the following decade. Both denotational semantics and axiomatic semantics are downstream of McCarthy’s proposal.
The International Federation for Information Processing Working Group 2.1 began work on a successor to ALGOL sixty in nineteen sixty-four. The working group’s charter was to design a new algorithmic language that would supersede ALGOL sixty as the reference notation for algorithm publication and, if possible, as an implementation language. The design process was substantially more contested than the ALGOL sixty process had been.
Adriaan van Wijngaarden at the Mathematical Centre in Amsterdam proposed a description technique called the two-level grammar, which later became known as the van Wijngaarden grammar. The technique addressed a specific limitation of Backus-Naur form, namely that context-sensitive constraints of a language, such as the requirement that a variable be declared before it is used, cannot be expressed in a context-free grammar alone. The two-level grammar supplied one context-free grammar for metasyntactic categories and a second context-free grammar generated from the first for the object-language syntax. The technique allowed precise and machine-checkable description of context-sensitive constraints.
The two-level grammar gave the ALGOL sixty-eight report a level of precision that no prior programming language definition had achieved. It also made the report substantially harder to read than the ALGOL sixty report had been. The working group was divided on the question of whether the precision was worth the readability cost. A minority position, recorded in a Minority Report signed by Edsger Dijkstra, Niklaus Wirth, C. A. R. Hoare, Brian Randell, and several other members, argued that the language had become too complex and its description too opaque. The majority position prevailed.
The final draft of the ALGOL sixty-eight report was adopted by the working group on December twentieth of nineteen sixty-eight at a meeting in Munich and approved for publication by the General Assembly of the International Federation for Information Processing. The editors of the report were A. van Wijngaarden, B. J. Mailloux, J. E. L. Peck, and C. H. A. Koster. A Revised Report appeared in nineteen seventy-six, with Lambert Meertens among the editors.
ALGOL sixty-eight consolidated a substantial number of language design ideas into a single framework, including a type discipline that distinguished modes from values, first-class references, overloaded operators, and an orthogonal treatment of the interaction between control structures and expressions. The language was implemented in several places but was not widely adopted as an industrial language. Its principal legacy is the two-level grammar and the design lesson that precision of description and readability of the description can conflict and that committee design processes should treat that conflict explicitly rather than hope it will resolve itself.
Corrado Böhm and Giuseppe Jacopini published a paper in Communications of the ACM in May nineteen sixty-six titled Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules. The paper proved that any program expressed as a flow chart could be rewritten as an equivalent program using only sequential composition, conditional selection, and iteration, without any unconditional branch instruction. The proof demonstrated that the goto statement was not necessary for computational completeness. The three constructs were sufficient.
Edsger Dijkstra’s letter Go To Statement Considered Harmful appeared in Communications of the ACM in March nineteen sixty-eight. The letter argued that programs whose control flow depended on unconditional branch instructions were substantially harder to reason about than programs that used only structured control constructs. Dijkstra’s argument rested on a specific observation. The state of a program at a given point in its source code determines the possible executions that reach that point. A program that uses only structured constructs has a simple relationship between source code position and possible executions. A program that uses unstructured control flow has a substantially more complex relationship because the possible executions that reach a given source code position include any execution that could branch to that position.
Dijkstra’s letter, titled Go To Statement Considered Harmful by the editor Niklaus Wirth rather than by Dijkstra himself, launched a decades-long controversy that eventually resolved in favor of Dijkstra’s position. Structured programming became the default in new language design and software engineering practice. The controversy was substantive rather than merely stylistic because the transition required programmers and language designers to give up a specific technique that was in wide use and, in exchange, receive a discipline whose benefits were only fully realized in the collective behavior of large software systems.
The Böhm-Jacopini theorem provided the mathematical basis for the transition. Dijkstra’s letter provided the engineering argument for it. The two together established that the goto statement was avoidable and its avoidance was worth the cost.
Charles Antony Richard Hoare published An Axiomatic Basis for Computer Programming in Communications of the ACM volume twelve, issue ten, in October nineteen sixty-nine. The paper introduced what became known as Hoare logic, a formal system for proving that a program satisfies a specification.
The system
uses
assertions
about
the state of a program
at particular points
in its execution.
An assertion
takes the form
of a predicate
over
the values of program variables.
A Hoare triple,
written {P} S {Q},
consists of
a precondition assertion P,
a program statement S,
and
a postcondition assertion Q.
The triple
asserts
that
if the precondition holds
before
the statement executes
and the statement terminates,
then
the postcondition holds
afterward.
Hoare’s paper
gave
axiomatic rules
for the standard programming constructs
of a simple imperative language.
Assignment
had
an axiom,
written {P[E/x]} x := E {P},
which reads
that the postcondition P
on the assigned variable x
holds after the assignment
provided
the postcondition
with the expression E
substituted for x
held before.
Sequential composition
had
a rule
that combined
two triples
whose postcondition and precondition
matched.
Conditional selection
had
a rule
that reasoned about
each branch separately.
Iteration
had
a rule
that used
a loop invariant,
which is
an assertion
that holds
before the loop begins,
before every iteration,
and after the loop terminates.
The rules together
provided
a mechanical procedure
for reducing
the proof
that a program
satisfied
its specification
to
the proof
of a set of first-order logic obligations
called
verification conditions.
Hoare’s axiomatic method became the basis for program verification tools throughout the following decades. The Alan Turing Award that Hoare received in nineteen eighty cited this contribution as its central justification. The method also established the discipline of program specification as a distinct research program, which subsequent work in formal methods, model checking, and proof assistants would develop.
Christopher Strachey at Oxford University had begun a research program on the mathematical semantics of programming languages in the mid nineteen sixties. His nineteen sixty-six lecture Fundamental Concepts in Programming Languages, delivered at a summer school in Copenhagen, laid out a research agenda for treating programming language constructs as mathematical objects. The lecture distinguished L-values from R-values, namely the value that a variable name denotes when it appears on the left-hand side of an assignment from the value it denotes when it appears on the right-hand side. The distinction had been implicit in the treatment of ALGOL sixty but Strachey’s lecture made it explicit.
Dana Scott visited Strachey’s group at Oxford in the autumn of nineteen sixty-nine while on sabbatical from Princeton University. Scott joined the Oxford faculty formally in nineteen seventy-two as Professor of Mathematical Logic. Scott had been working independently on the mathematical foundations of computation. His nineteen sixty-nine paper Outline of a Mathematical Theory of Computation, delivered at the Princeton Fourth Annual Conference on Information Sciences and Systems, sketched a domain-theoretic approach to the mathematical semantics of recursive definitions. Scott’s approach addressed a specific technical problem, namely the interpretation of recursive function definitions as mathematical objects. A recursive definition looks like an equation that a function must satisfy, but the ordinary rules for solving equations do not apply directly because the space of functions is not a set in the ordinary sense. Scott’s domain theory provided the space in which the equation had a solution.
The Scott and Strachey collaboration produced the paper Toward a Mathematical Semantics for Computer Languages, published in nineteen seventy-one by the Oxford University Computing Laboratory Programming Research Group. The paper launched what became known as denotational semantics or, in early literature, as mathematical semantics or Scott-Strachey semantics. The next article in this series will develop the denotational program in its nineteen seventies mature form.
The nineteen sixties supplied four things that the following decade consumed.
First, a research program in mathematical semantics, begun by McCarthy, extended by Strachey and Scott, that would produce denotational semantics as a working discipline in the nineteen seventies.
Second, a mechanical proof technique for program correctness, namely Hoare’s axiomatic method, that would produce axiomatic semantics as a companion approach to the denotational program.
Third, a class of programming languages whose constructs were directly translatable into lambda calculus, in Landin’s ISWIM sense, which would produce Standard ML, Miranda, and the modern family of statically typed functional languages in the nineteen seventies and nineteen eighties.
Fourth, a class of programming languages whose constructs included classes, inheritance, and virtual procedures, in Simula sixty-seven’s sense, which would produce Smalltalk, C plus plus, Java, and the object-oriented family in the following two decades.
The decade also established two disciplinary questions that would organize programming language theory from then on. The first asks what a program means mathematically, which denotational and axiomatic semantics answer differently. The second asks what disciplines a programmer should submit to to write correct programs, which structured programming, type systems, and formal specification answer differently. The following article develops these questions in the nineteen seventies.
The nineteen sixties turned the pre-nineteen-sixty foundations into a research discipline with a research agenda, a formalism, a proof technique, and a small set of exemplar languages that would organize subsequent work. The decade did not resolve the questions it opened. It made them sharp enough to be worked on in subsequent decades.
The next article, A209, covers the first half of the nineteen seventies, during which the denotational semantics program matured and the pragmatic side of the decade produced Pascal and C.
Programming language theory inherits its vocabulary from a small handful of mathematical papers written between nineteen thirty and nineteen sixty. The papers belong to logic and to computability theory, not to computer science in the modern sense, because computer science in the modern sense did not yet exist. They were written to answer questions about the foundations of mathematics. They answered those questions and, as a side effect, gave the discipline of programming its central abstractions.
Every recurring thread that the opener article to this series named has an origin in this period. Type systems trace to Alonzo Church’s simply typed lambda calculus of the nineteen forties. Semantics traces to the reduction rules Church wrote for the untyped lambda calculus of the nineteen thirties. Effect systems trace to Alan Turing’s model of state-carrying computation. Recursive function theory and the productivity discipline trace to Stephen Kleene’s work on recursive functions. Even the syntax of programming languages traces to this period, through John Backus’s normal form for describing ALGOL fifty-eight and Peter Naur’s extension for ALGOL sixty.
This article walks the pre-nineteen-sixty foundations in the order the papers appeared. The order matters because each later paper depends on the earlier ones, either directly by extending them or indirectly by being a reaction to their limits.
Alonzo Church introduced the lambda calculus in a nineteen thirty-two paper in the Annals of Mathematics titled A Set of Postulates for the Foundation of Logic. The paper’s stated purpose was the construction of a foundation for mathematical logic free of the paradoxes that had troubled Bertrand Russell’s system. Church’s students Stephen Kleene and John Barkley Rosser soon proved that the original system was inconsistent. The subset that avoided the paradox became the lambda calculus in the modern sense.
The system’s central idea
is that a function
is a rule
written directly
rather than a mathematical object
extracted from a larger context.
The identity function
is written
λx.x.
The function that adds one to its argument
would be written
λx.x+1
if the calculus admitted a plus operator.
The pure calculus admits only
variables,
abstractions of the form
λx.M
where M is any term,
and applications of the form
(M N)
where M and N are any terms.
Everything else
is built up
from these three constructions.
Church published two further papers in nineteen thirty-six. A Note on the Entscheidungsproblem appeared in the Journal of Symbolic Logic in March. An Unsolvable Problem of Elementary Number Theory appeared in the American Journal of Mathematics in April. The two papers together proved that the decision problem for first-order predicate calculus is unsolvable, which is the negative answer to Hilbert’s Entscheidungsproblem. The proof depended on the lambda calculus as its model of computation and articulated what came to be called Church’s thesis, namely that the effectively calculable functions are exactly the lambda-definable functions.
The definitive presentation of the system is Church’s nineteen forty-one monograph The Calculi of Lambda-Conversion, published by Princeton University Press as volume six of the Annals of Mathematics Studies. The monograph consolidates the reduction rules, the confluence property, and the equivalence between lambda-definability and general recursiveness. It is the primary source for every subsequent treatment of the untyped lambda calculus.
Church also introduced the simply typed lambda calculus in a nineteen forty paper titled A Formulation of the Simple Theory of Types, which appeared in the Journal of Symbolic Logic. The simply typed calculus adds a type discipline in which every variable carries a type annotation and every application requires the operator’s type to match the operand’s type. The paper is the origin of every subsequent type system in the programming-languages literature.
Moses Schönfinkel delivered a talk in December nineteen twenty in Göttingen titled Elemente der Logik. The talk introduced what became combinatory logic in its published form. The paper Über die Bausteine der mathematischen Logik appeared in nineteen twenty-four in Mathematische Annalen. Schönfinkel’s project was the elimination of bound variables from mathematical logic. He showed that every logical expression that uses variables can be rewritten as a composition of two primitive constants, which he named S and K.
The K combinator
returns its first argument
and discards the second.
Its defining equation
is
K x y = x.
The S combinator
takes three arguments
and returns
the first applied to the third
applied to
the second applied to the third.
Its defining equation
is
S x y z = (x z) (y z).
Every closed lambda expression
can be rewritten
as a combination of S and K,
so combinatory logic
and lambda calculus
compute
the same class of functions.
The equivalence
is the reason
combinatory logic
remains
a working alternative formulation
of the same computational content.
Haskell Curry rediscovered Schönfinkel’s combinators independently while working as an instructor at Princeton University in late nineteen twenty-seven. His nineteen thirty dissertation Grundlagen der Kombinatorischen Logik, published in the American Journal of Mathematics, systematized the treatment of combinatory logic as an alternative foundation to Russell’s type theory. Curry’s subsequent work extended combinatory logic to a system that could interpret substantial fragments of mathematical logic. The definitive presentation is the monograph Combinatory Logic that Curry published with Robert Feys in nineteen fifty-eight.
The relationship between combinatory logic and lambda calculus is that the former compiles the latter. A term in the lambda calculus can be translated to a combinator expression by the bracket abstraction algorithm. The resulting expression uses no variables and evaluates by reduction rules that are structurally simpler than the substitution rule of the lambda calculus. Combinatory logic is thereby an early example of a target language for a source-language compiler.
Alan Turing introduced what came to be called Turing machines in On Computable Numbers, with an Application to the Entscheidungsproblem, which appeared in the Proceedings of the London Mathematical Society, Series 2, Volume 42, in the November thirtieth and December twenty-third issues of nineteen thirty-six. A two-page correction appeared in the same journal, Volume 43, in nineteen thirty-eight. Turing published his paper independently of Church. Turing added an appendix proving the equivalence of his machines with the lambda calculus, and a fuller proof appeared in his nineteen thirty-seven paper Computability and Lambda-Definability in the Journal of Symbolic Logic.
Turing’s model is a machine with a finite state controller and an infinite tape that the controller reads from and writes to one cell at a time. The controller is defined by a transition table that maps a pair of current state and current tape symbol to a triple of new state, new tape symbol, and direction of tape motion. The machine halts when the transition table has no entry for the current pair. A number is computable if a Turing machine exists that, starting from a standard initial tape, eventually halts with the number represented on its tape.
Turing’s argument in the paper addressed the same Entscheidungsproblem that Church had addressed in his own nineteen thirty-six papers. Turing proved that there is no general algorithm that, given a description of a Turing machine and an input tape, decides whether the machine halts. The halting problem is the founding negative result of computability theory.
The Turing machine matters to programming language theory for two reasons. First, it provides a model of computation that carries state in a manifestly imperative form. Every subsequent imperative language and every subsequent operational semantics draws on this state-carrying picture, directly or by analogy. Second, it provides the definitional standard for what an algorithm is. A language is Turing-complete if it can simulate an arbitrary Turing machine, and the notion of Turing-completeness is the terminological anchor for expressiveness comparisons between languages.
Church and Turing worked independently. Church’s lambda calculus and Turing’s machine were shown to be equivalent in nineteen thirty-six and nineteen thirty-seven. The equivalence established that the class of computable functions does not depend on the model chosen. Recursive functions, lambda-definable functions, and Turing-computable functions are the same class.
The mathematical equivalence between the three formulations is a theorem. The Church-Turing thesis is a stronger claim, that this shared class of functions is exactly the class of effectively calculable functions in the informal sense. In its strongest form, which treats the class as the class of physically realizable computations, the thesis remains a conjecture rather than a theorem. The three original formulations converge on the same class of functions by mathematical proof. Whether that class is the class of all possible computations is a separate, still-open, question.
The equivalence is the reason programming language theory does not need to choose between the imperative and the functional picture as the foundation of the discipline. Either picture suffices. The choice is a matter of engineering convenience, of what a specific language is designed to make easy.
Kurt Gödel introduced the class of general recursive functions in a nineteen thirty-four Princeton lecture series at the Institute for Advanced Study. Stephen Kleene and John Barkley Rosser took notes, which the Institute mimeographed and distributed under the title On Undecidable Propositions of Formal Mathematical Systems. Gödel’s construction built on Jacques Herbrand’s earlier work on definitions by equations. Stephen Kleene subsequently extended and refined the treatment in his nineteen thirty-six paper General Recursive Functions of Natural Numbers, published in Mathematische Annalen. Kleene’s nineteen fifty-two monograph Introduction to Metamathematics became the standard graduate-level reference for recursive function theory.
Recursive function theory matters to programming language theory in three ways. First, it supplies a third equivalent characterization of the computable functions, alongside Church’s lambda calculus and Turing’s machines. Second, the primitive recursive functions, which form a proper subclass of the general recursive functions, are the historical origin of the totality analyses that modern definitive-bound languages enforce. A function that is primitive recursive is provably total. Third, the recursion theorems that Kleene proved are the technical basis for reasoning about fixed points, self-reference, and the semantics of recursive definitions in later work.
John von Neumann’s First Draft of a Report on the EDVAC, completed on June thirtieth nineteen forty-five, consolidated the design principle that a machine’s program and its data should share the same memory and be encoded in the same form. The report drew on work by J. Presper Eckert and John William Mauchly at the Moore School of the University of Pennsylvania, where the ENIAC was being built and the EDVAC was being designed. The First Draft was an internal report rather than a formal publication, and its attribution has been contested because Eckert and Mauchly’s contributions predate the report. The report nevertheless became the disseminating document for the stored-program architecture.
The stored-program architecture matters to programming language theory because it makes the identification of programs with data concrete at the machine level. A compiler that reads a source program as input and writes an executable program as output is a program that computes on programs. The stored-program picture provides the operational substrate that makes this identification routine. Church’s lambda calculus had already established the identification at the mathematical level. The stored-program architecture made it engineering fact.
John Backus proposed what became FORTRAN in a November nineteen fifty-three memorandum to his manager at International Business Machines. The language definition was completed in late nineteen fifty-four. The compiler was programmed and tested across nineteen fifty-five and nineteen fifty-six. The FORTRAN Automatic Coding System for the International Business Machines seven oh four shipped to customers in April nineteen fifty-seven.
FORTRAN was not the first high-level programming language. Grace Hopper’s A-0 system of nineteen fifty-one, Alick Glennie’s Autocode of nineteen fifty-two for the Manchester Mark One, and other early systems predated it. FORTRAN was the first high-level language whose compiler produced code that ran comparably to hand-written assembly. Backus’s team implemented an aggressive optimizing compiler whose output was within a small constant factor of what a human programmer could write directly. The comparable-performance property was what made high-level programming economically viable.
FORTRAN matters to programming language theory for a specific reason. It established the principle that a language can be more abstract than the machine it runs on without paying an unacceptable performance cost. Every subsequent optimizing compiler is downstream of the FORTRAN demonstration. The FORTRAN team also introduced several ideas that later became standard, including loop-invariant code motion, common-subexpression elimination, strength reduction on index expressions, and register allocation by ad hoc heuristics that later work would supersede with graph-coloring approximations.
John McCarthy began developing LISP at the Massachusetts Institute of Technology in late nineteen fifty-eight. The language grew out of his effort to define a computable analogue of the recursive functions that operate on symbolic expressions rather than on numbers. The seminal paper Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part One appeared in Communications of the ACM, Volume 3, Number 4, in April nineteen sixty. Part Two was never published.
LISP’s central data structure is the cons pair, a two-field record whose fields hold either atoms or other cons pairs. The language uses the same notation for programs and for data, so a program is a list that can be manipulated by other programs. The identification of program with data is Church’s identification made syntactically direct. The property is the basis for LISP macros and for the metacircular evaluator, which is the definition of the LISP evaluator in LISP itself.
The nineteen sixty paper introduced automatic memory management through garbage collection. Steve Russell, McCarthy’s student, had implemented the first working LISP interpreter in nineteen fifty-nine by hand-translating McCarthy’s eval function into assembly code for the International Business Machines seven oh four. The interpreter demonstrated that the metacircular evaluator was executable in practice rather than only notational.
LISP matters to programming language theory in several ways. The garbage-collection technique became the standard memory-management strategy for functional languages, for many object-oriented languages, and for most modern scripting languages. The identification of program with data became the foundation of macro systems in the Scheme, Common Lisp, and Racket traditions. The metacircular evaluator became the pedagogical template for understanding how an interpreter works, which Harold Abelson and Gerald Sussman would later make canonical in Structure and Interpretation of Computer Programs.
A joint committee of the American Association for Computing Machinery and the German Society for Applied Mathematics and Mechanics, the Gesellschaft für Angewandte Mathematik und Mechanik, met at the Federal Institute of Technology in Zurich from May twenty-seventh to June second of nineteen fifty-eight. The German-side delegation was Friedrich Bauer, Hermann Bottenbruch, Heinz Rutishauser, and Klaus Samelson. The American-side delegation was John Backus, Charles Katz, Alan Perlis, and Joseph Wegstein. The committee produced the preliminary report on the International Algebraic Language, which was subsequently renamed ALGOL, which stood for Algorithmic Language. The preliminary specification was published in December nineteen fifty-eight and became known as ALGOL fifty-eight.
ALGOL fifty-eight introduced several features that became standard in subsequent languages, including block structure, lexical scope, and call-by-name parameter passing. The language was intended as a publication language for algorithms rather than as an implementation language, and its specification therefore emphasized readability and precision over ease of compilation.
The language description posed a specific problem for the committee. Existing programming languages were described in natural language prose with representative examples, which left ambiguities that different implementers resolved differently. John Backus proposed a formal notation for describing the syntax of the language. His nineteen fifty-nine paper The Syntax and Semantics of the Proposed International Algebraic Language of the Zurich ACM-GAMM Conference, delivered at the International Conference on Information Processing in Paris, introduced what he called the metalinguistic formulae. Peter Naur revised the notation for the ALGOL sixty report and it became known as Backus normal form. Donald Knuth argued in a nineteen sixty-four letter to Communications of the ACM that Backus normal form was not a normal form in any technical sense. Knuth proposed the rename to Backus-Naur form to credit Naur and preserve the abbreviation, and the rename prevailed.
A Backus-Naur form production
has
the shape
<nonterminal> ::= <alternative-1> | <alternative-2> | ...,
where each alternative
is a sequence of nonterminals
and terminal symbols.
The notation
is
a context-free grammar
in a specific syntactic dress.
It is
the origin
of every subsequent
formal syntax specification
in programming language theory.
Every parser generator,
every language reference manual
that carries a grammar section,
and every proof-assistant formalization
of a language syntax
descends from
the metalinguistic formulae
that Backus introduced
in nineteen fifty-nine.
The joint committee reconvened in Paris from January eleventh to sixteenth of nineteen sixty. The thirteen-member committee included John Backus, Friedrich Bauer, and several delegates from the ALGOL fifty-eight process. Peter Naur served as editor and rapporteur. The Report on the Algorithmic Language ALGOL 60 was published in May nineteen sixty in Communications of the ACM and simultaneously in the German journal Numerische Mathematik. A revised report was published in Communications of the ACM in January nineteen sixty-three.
ALGOL sixty consolidated the innovations of ALGOL fifty-eight into a complete language definition that included recursion, lexically scoped local variables, dynamic array allocation, and a formal syntax in Backus-Naur form. The language was never widely used as an industrial implementation language, but it became the reference notation for algorithm publication in the ACM literature for two decades. Every ACM algorithm publication until the mid nineteen eighties appeared in an ALGOL sixty subset.
ALGOL sixty matters to programming language theory because it consolidated the discipline’s technical vocabulary. The terms block structure, lexical scope, call-by-value, call-by-name, type declaration, formal parameter, and actual parameter appear in the ALGOL sixty report in the sense they carry today. Every subsequent programming language either extends the ALGOL sixty vocabulary or explicitly rejects it. The report is the vocabulary reference for the next fifty years of language design.
The pre-nineteen-sixty foundations supply the mathematical and terminological infrastructure that the nineteen sixties will use to consolidate programming language theory as a research discipline. Specifically, the era supplies three things that the next article in this series will pick up.
First, two independent mathematical models of computation, the lambda calculus and the Turing machine, that were proved equivalent in nineteen thirty-six and nineteen thirty-seven. The equivalence underwrites the discipline’s ability to move between imperative and functional formulations without loss of expressive power.
Second, a small but growing set of practical high-level languages, FORTRAN, LISP, and ALGOL fifty-eight, that demonstrated the feasibility of programming above the machine-code level. The demonstrations made the discipline economically defensible. Before them, high-level programming was an academic curiosity. After them, it was an industrial necessity.
Third, a formal notation for describing language syntax, namely Backus-Naur form, which made it possible to state precisely what a language is rather than to convey it by example. The notation is the essential enabler of every subsequent formal-semantics program, which the next article will begin to develop.
Programming language theory before nineteen sixty was not yet programming language theory. It was mathematical logic, computability theory, and early computer engineering, each pursuing its own questions. The questions converged on a small set of shared objects, namely computable functions, formal syntax, and stored-program machines, that would become the material of the discipline in the next decade.
The next article, A208, covers the nineteen sixties.
Programming language theory is the intellectual project of asking what a program means before asking what a program does. The project began before the first practical compiler and continues today in academic conferences, industrial toolchains, and the small handful of production languages whose central design goal is a verified property rather than a runtime behavior. The arc from foundations to present-day production practice runs about seventy years if the count begins with Alonzo Church’s lambda calculus of the nineteen thirties, about fifty years if the count begins with the first ACM Symposium on Principles of Programming Languages in October nineteen seventy-three in Boston, Massachusetts, and about thirty years if the count begins with the maturation of type theory into an engineering discipline in the mid nineteen nineties. Any of the three starting points tells a coherent story. The story ends at the present moment.
This article opens a ten-article back-dated series that traces the arc from foundations to the current state of the practice. The purpose of the series is instrumental. The historical treatment is a scaffold for the periodic current-event surveys that follow the arc. A reader who arrives at a modern development without the background of Hindley-Milner unification, Reynolds’s parametricity, or Denning’s information-flow lattice cannot judge whether the development is a substantive advance or a rediscovery. The arc supplies the background. The current-event surveys apply it.
The series is not the first back-dated historical treatment in this corpus. A History of Hardware Description Languages covers the parallel arc for the languages that describe circuits rather than programs, and the stream-based compilers series covers a specific compiler-architecture tradition across twelve articles. The present series is the third sustained historical treatment, and it consumes the article numbers A206 through A215 across the ten consecutive days 2026-03-27 through 2026-04-05, concluding one day before the stream-based compilers series begins at A188 on 2026-04-06. The two blocks form a contiguous historical spine running from the current article through to the end of April.
The choice of a chronological treatment over a theme-based lineage treatment is deliberate, and it is worth defending. A theme-based treatment picks one intellectual thread, for example the development of type systems from Curry through Hindley, Milner, Reynolds, and Pierce to current dependent-type practice, and follows the thread across every decade in which it is active. The theme-based treatment honors the internal logic of each thread but conceals the interactions between threads.
The chronological treatment does the opposite. It picks a decade and asks what every active thread was doing in that decade. The trade-off is real. A chronological article must break each thread at the decade boundary and reintroduce it in the following article. The gain is the coherent picture of a specific research moment, which is what the reader needs if the destination of the series is a synthesis of present-day work.
The historical eras that this series treats receive different levels of coverage because the density of substantive developments was not the same across decades. The nineteen seventies receive two articles because the decade delivered Hindley-Milner inference, denotational semantics in the form Christopher Strachey and Dana Scott gave it, Robin Milner’s Logic for Computable Functions and the first ML, the earliest work on dependent types in Per Martin-Löf’s type theory, and the founding of the ACM Symposium on Principles of Programming Languages. The nineteen eighties receive one article even though Prolog matures, the Haskell precursors form, category theory becomes a working tool of language semantics, effect systems formalize in Gifford and Lucassen’s work, and object-oriented programming matures through Smalltalk with the founding of OOPSLA in nineteen eighty-six, because each of those developments extends rather than opens a research direction.
Every article in this series ends by naming what the developments of the era enable in later work. The purpose is not antiquarian. The purpose is to arm the reader to read a current-day paper or product announcement and immediately place the work against its intellectual predecessors.
The concrete example that motivates the series is information-flow control. Denning’s original nineteen seventy-six lattice paper formalized the mathematical structure of information-flow constraints in a way that lay dormant for close to two decades. Andrew Myers’s work on JFlow at Cornell in the late nineteen nineties, alongside Heintze and Riecke’s SLam calculus of nineteen ninety-eight, revived the mathematical program in a practical form. Sabelfeld and Myers’s two thousand three survey and Pottier and Simonet’s Flow Caml consolidated the state of the practice. The twenty twenties have seen information-flow labels appear in production language design. Keleusma’s information-flow-labels chapter describes one such adoption, and an earlier article of this blog develops the practical use of the pattern.
A reader who arrives at Keleusma’s labels without the arc sees a language feature. A reader who arrives with the arc sees a nineteen seventy-six theorem that took fifty years to reach a production language, and they understand why the intervening decades were needed. The same story holds for refinement types, for coroutine-based concurrency, for dependent-type surface syntax, and for the totality and productivity disciplines that a modern definitive-bound language enforces.
The remaining nine articles divide the arc as follows.
Every era article in this series carries a set of recurring threads that the reader can trace across decade boundaries. The threads are not independent research programs. They interact, and part of the value of a chronological treatment is showing the interactions.
The principal threads are the following.
A reader who follows one thread across the arc sees a specific intellectual project develop. A reader who reads the arc chronologically sees which threads were active together at each moment.
The series follows the epistemic conventions established in the compilers series and the hardware description language history. Facts, inferences, and hypotheses are distinguished explicitly. Uncertainty markers are stated rather than elided. Primary sources are cited where they exist. Standard secondary references are cited for consolidated treatments.
The consolidated references for this arc are the four History of Programming Languages conferences, each of which produced substantial proceedings. The first, in nineteen seventy-eight in Los Angeles, was chaired by Jean E. Sammet as both general and program chair with Richard L. Wexelblat as proceedings chair. The second, in nineteen ninety-three in Cambridge, Massachusetts, was chaired by John A. N. Lee with Jean E. Sammet as program chair. The third, in two thousand seven in San Diego, consolidated another wave of developments. The fourth, originally scheduled for June twenty twenty and held in two thousand twenty-one after the pandemic delay, brings the record close to the present. The four HOPL proceedings are the authoritative primary-source-oriented survey documents of the field.
Three canonical textbooks appear throughout the series as consolidation-of-record references. Benjamin C. Pierce’s Types and Programming Languages, published by the MIT Press in two thousand two, is the graduate-level type-systems reference. Glynn Winskel’s The Formal Semantics of Programming Languages, published by the MIT Press in nineteen ninety-three, is the operational semantics reference. John C. Reynolds’s Theories of Programming Languages, published by Cambridge University Press in nineteen ninety-eight, is the broad theoretical-basis reference that covers imperative and functional programming in a single treatment. Each of the three is cited where the era article’s development depends on the treatment the textbook consolidates.
The current-day publication venues that supply the material for the later current-event surveys are the ACM SIGPLAN conferences. The Symposium on Principles of Programming Languages founded in nineteen seventy-three publishes theory-forward work. The International Conference on Functional Programming founded in nineteen ninety-six publishes functional-language work. The Programming Language Design and Implementation conference began in nineteen seventy-nine as the SIGPLAN Symposium on Compiler Construction and adopted its current name in nineteen eighty-eight. Object-Oriented Programming Systems Languages and Applications founded in nineteen eighty-six publishes object-oriented and adjacent work. The four together are the primary current-venue signal that the surveys at the end of the arc will consume.
The programming-language-theory arc is not a standalone piece. It sits next to three other sustained treatments in this corpus.
The stream-based compilers series at A188 through A199 covers a specific compiler-architecture tradition from Wirth’s PL/0 pedagogy of nineteen seventy-six to the present-day WebAssembly single-pass validator and coroutine-based embedded-scripting family. The current series supplies the intellectual context that makes the compiler-architecture tradition readable. Wirth’s PL/0 is not a random choice of a pedagogical language. It sits in a specific place in the type-systems and structured-programming threads.
The hardware description language history at A200 and its companion articles at A201 through A204 cover the parallel language tradition for circuits. The current series supplies the intellectual context for why the embedded-domain-specific-language revival in the twenty tens happened and why it happened in the languages it happened in.
The Keleusma articles at A107, A110, and A205 walk the reader through one specific production language that pulls several threads of programming-language theory into a single small implementation. The current series supplies the intellectual context for why those threads are the right threads to pull in.
The three prior treatments are pre-existing background that the current series was constructed to make legible. A reader who reads the current series first will find the prior treatments better contextualized. A reader who reads the current series last will find that it consolidates what the prior treatments were doing without saying.
The series is deliberately a survey rather than a monograph. The genuine standard for a monograph on the history of programming language theory is set by the four HOPL proceedings and by the graduate-level textbooks named earlier. This series does not attempt that level of depth.
The series is also not a substitute for the current-event surveys it introduces. The historical arc establishes the context. The current-event surveys consume the context and apply it to specific developments as they emerge. A reader who wants the current state of the practice should read the current-event surveys. A reader who wants the historical context that makes the current-event surveys readable should read the historical arc.
The series is also not a Turing-award citation. The Turing award has been given to individuals whose work shaped programming language theory, and their names appear throughout the arc. But the citations are situated within their intellectual moment rather than presented as biographical retrospectives. A reader who wants biographical retrospectives should consult the ACM Turing Award citations directly.
Programming language theory is a coherent intellectual project with a fifty-year to seventy-year arc, depending on where the count begins. The arc runs from Alonzo Church’s lambda calculus through the founding of the ACM Symposium on Principles of Programming Languages in nineteen seventy-three in Boston, through the maturation of type theory into an engineering discipline, to the current state of the practice in which several fifty-year-old theorems appear as production language features. This series traces that arc in ten articles across ten consecutive days in a back-dated block that ends flush against the stream-based compilers series. The purpose is instrumental. The historical treatment supplies the context that later current-event surveys consume.
The next article, A207, covers the foundations before nineteen sixty.