Simon Jones on Functional Programming, Thinking in Types, Useless Languages

# Simon Jones on Functional Programming, Thinking in Types, and Hardware for Functional Languages **TL;DR:** Simon Peyton Jones, co-founder of Haskell, explains that functional programming—programming with values rather than state changes—is mathematically sound, offers better maintainability by forcing explicit data flow, and has influenced mainstream languages with ideas like garbage collection and type systems, despite the inconvenience of handling side effects. ## What Is Functional Programming? Functional programming is programming through values rather than state changes. In traditional imperative programming, computation relies on mutable state. For example, to sum numbers from 1 to 100, you’d have a mutable unit holding a running total, updated step by step. This approach involves a program counter and evolving state, which is very different from mathematical reasoning. As Simon Jones explains, when you evaluate `3 + 4 * 7` in math, you don’t think of a mutable unit changing over time; you see it as a declarative expression. Functional programming works similarly to an electronic spreadsheet: a cell formula like `=A2 * A3 + 7` is evaluated based on the current values of A2 and A3, with no program counter or sequence of execution. Jones emphasizes that functional programs can be surprisingly powerful, even without traditional state changes. He recalls his initial shock at learning that functions alone could express useful computations, challenging his earlier view that computation and state changes were inseparable. ## Historical Context: Turing Machines vs. Lambda Calculus The roots of functional programming trace back to the 1930s, with two models of computation: Alan Turing’s Turing machine (based on state changes) and Alonzo Church’s lambda calculus (without state changes). Both models are computationally equivalent—anything one can compute, the other can too. This equivalence was surprising to Jones. From this foundation, functional programming emerged as an academic approach, initially seen as quirky but intellectually rich. Jones dedicated his research career to exploring the “values-only” paradigm, discovering that it could lead to programs that are easier to write, maintain, and reason about. ## Benefits of Functional Programming One key advantage is maintainability. Imperative code often relies on global variables, creating hidden couplings between code modules. Changing the order of operations or modifying shared state can lead to unexpected bugs, especially in legacy code. Functional programming forces these couplings to be explicit, encouraging modular design and making systems easier to refactor safely. Jones notes that functional programming ideas have been absorbed into mainstream languages—think garbage collection, lambda expressions, type systems, and polymorphism. While imperative languages have adopted these concepts, he argues that starting from a functional base and adding imperative features where necessary might be more effective than the reverse. The approach also enhances reasoning about code. By eliminating side effects by default, functional languages make it easier to prove correctness and avoid common pitfalls. As Jones puts it, “When the limestone layer of imperative programming is worn away, the granite of functional programming is revealed.” ## Challenges and Side Effects Functional programming isn’t without drawbacks. Pure functional languages forbid side effects, which can be inconvenient for tasks like getting the current time or performing I/O. Jones uses Haskell as an example: it provides a controlled escape hatch called `unsafePerformIO`, which allows side effects but requires the programmer to guarantee safety. The name includes “unsafe” to emphasize responsibility—something imperative programmers handle constantly without a second thought. ## Hardware for Functional Programming In the late 1970s, John Backus (designer of Fortran) gave a Turing Award lecture urging a shift to functional programming. He even proposed designing hardware for functional languages. This idea led to experiments like Lisp machines from Symbolics and the MIT dataflow project, which created the Monsoon machine for executing dataflow (functional) programs. Closer to functional programming’s roots, the SKI machine was built in the UK to directly execute SK combinators. The SKI machine ran programs encoded as SK combinators, offering a hardware-level approach to functional computation. ## SK Combinators Explained Jones describes the SK combinators (S, K, and I) as a minimal set of combinators that can simulate any lambda calculus program. Their reduction rules are simple: - `I x = x` - `K x y = x` - `S x y z = (x z) (y z)` Any lambda expression can be converted into SK combinators—a transformation that’s straightforward to implement. For example, a program can be represented as a tree of S and K combinators, and execution proceeds by applying these rules repeatedly. This method is so effective that some Haskell implementations, like microH by Lennart Augustsson, use SK reduction as their execution mechanism. ## Source [Simon Jones on Functional Programming, Thinking in Types, Useless Languages](https://www.youtube.com/watch?v=xcB_LF3cdqw)