How to Get People Excited about Functional Programming • Russ Olsen & James Lewis

In a conversation at GOTO Copenhagen 2024, Russ Olsen, author of “Getting Clojure,” shares his journey into functional programming (FP), the challenges of teaching its core concepts, and the engineering lessons from the Apollo program.

The Journey into Functional Programming

Russ Olsen describes his introduction to functional programming as similar to many others’: encountering smart people advocating for it as a superior method for reasoning about and testing code, followed by hitting a “brick wall” when trying to apply it practically. He compares the initial difficulty to the paradigm shift when developers were first told to stop using goto statements.

He argues that much of the literature on FP is well-meaning but unhelpful because it gets entangled in terminology (e.g., “monads,” “category theory”) and presents the final result of a long thought process. A more effective approach is to start from the beginning:

“These are an arbitrary set of rules that we’re imposing on our program because we think it will make the code easier to understand, easier to reason about.”

This foundational premise makes the concepts more accessible than jumping directly into abstract jargon.

Learning and Teaching Complex Concepts

A significant challenge in teaching FP is the reliance on mathematical examples, like the Fibonacci sequence. While mathematically sound, these examples don’t resonate with the day-to-day work of most programmers, who deal more with text, data structures, and complex business logic.

Olsen emphasizes that the choice of examples is critical. His own breakthrough in understanding Lisp came from implementing his own Lisp interpreter. This experience forms the basis of his new book, “The Lisp Adventure,” which teaches Lisp by guiding the reader through building one in Python. This bottoms-up, hands-on approach is an alternative to the traditional top-down explanation of concepts, reflecting his belief that there is no single correct way to teach or understand things.

Clojure in Practice

The discussion touches on Clojure’s nature as an “80-proof programming language”—highly concise and powerful. While its terseness can sometimes make code harder to read later (a “write-only” aspect), the Clojure community mitigates this by culturally adopting specific conventions and idioms. Interestingly, the community resists calling these “patterns” due to a historical aversion to the term, even though they serve the same purpose.

When questioned about Clojure’s viability for production, Olsen provides a powerful existence proof: his most recent job was at a bank with 100 million customers that operated as a “Clojure monoculture,” with nearly every line of backend production code written in Clojure.

Adopting Functional Programming

For those trying to introduce FP to teams accustomed to imperative or object-oriented styles, Olsen offers several pieces of advice:

1. Be Practical, Not Revolutionary: Avoid grand claims like “this will change your life.” Instead, frame it as an incremental improvement that makes specific parts of programming easier.
2. Use Concrete Analogies: The core proposition of FP is to make business logic behave like a pure function from a math library (e.g., cosine or absolute value). These functions are trusted because they are easy to test and have no side effects. The goal is to apply these same characteristics to application code.
3. Isolate, Don’t Eliminate, Side Effects: A common misconception is that FP aims to eliminate all side effects. This is impossible, as every useful program action (updating a database, writing a file, rendering UI) is a side effect. The actual goal is to build a core of pure, testable logic and push the necessary, messy side effects to the outer edges of the system.

It was also noted that good object-oriented programming often resembles functional programming, with minimal side effects and a focus on immutability. The key philosophical difference in the Clojure world is the idea of keeping data “stupid” (simple data structures) and operating on it with smart, separate functions, rather than encapsulating data and behavior together in objects.

Inspiration from “Moon Landings”

Olsen’s keynote, “To the Moon,” explores the profound, inspirational impact of the Apollo moon landings. He argues that while not everyone today has a single, shared cultural moment like Apollo, every developer has experienced their own personal “moon landing”—a book, a product, a mentor, or a piece of technology that inspired them to pursue their career. The talk is a call to recognize and discuss these shared, yet personal, sources of inspiration.

The Apollo program also serves as a case study in extreme engineering. They took the “insane” approach of developing highly dependent systems concurrently, praying they would integrate at the end. They operated with an incredible tolerance for risk, exemplified by landing on the moon with a vehicle that had only flown twice before and launching a mission into a thunderstorm, which resulted in the rocket being struck by lightning twice. This contrasts with modern software development’s focus on redundancy, highlighting a different philosophy of “engineering tolerance” born from physical constraints.

• Tags:
• Software Engineering
• Functional Programming
• Clojure
• Lisp
• Teaching
• Apollo Program
• Engineering Culture