Functional Languages and the Future of Programming (Part 1)

Functional programming is one of the fundamental divisions among programming languages, and can be traced back very early in programming history: notably to LISP and ML. This series interviews leading proponents of some current functional languages to look at their importance and influence.

Most of us learned how to program on imperative languages, where one statement follows another like a recipe. Loops carry out repetitive operations and if statements allow branching. To provide access to pre-defined sequences of code, the statements are organized into functions and subroutines.

In addition to imperative and functional programming, a third major division of programming languages is declarative programming, whose classic example is Prolog. In declarative programming, a programmer or administrator defines the desired state of a system, and the program brings it to that state. This form of programming appears widely in modern system administration tools such as Ansible, usually employing YAML files.

Some of the functional languages that are still considered contemporary are:

• Erlang, developed in the late 1980s
• Haskell, also developed in the late 1980s or early 1990s
• OCaml, released in 1996
• F#, Microsoft’s optimistic entry into this crowded field in 2002
• Scala, released in 2004

The buzz around these languages never translated into mass adoption, although O’Reilly Media, where I worked, put out books about several of the languages. For this series, I interviewed authors who worked with O’Reilly at that time. The series looks at how these languages are being used, how functional programming has contributed to the general field of computer science, and what has happened to professional programming in the interim.

This series divides the innovative features of functional programming into two categories. The first category is mostly syntactic and easy to learn; these features have been adopted by more popular languages in the imperative space. The second category is fundamental, and what really makes functional programming functional. This category lies across a conceptual gulf from imperative programming.

Noting this history, some of the experts I talked to for the series consider their languages (and perhaps functional languages in general) as laboratories for programming, where new ideas are discovered and then offered to the outside world. Francesco Cesarini, author of two O’Reilly books, Erlang Programming and Designing for Scalability with Erlang/OTP, would like to see functional programming taught in every Computer Science curriculum.

A Bit of Background on Functional Programming

Where did the term « functional programming” come from? One AI search tells me, « Peter Landin is credited with coining the term ‘functional programming’ as part of his work in the 1960s. » But I can’t find a source for that claim. Another search returns, « There isn’t a single person credited with inventing the term `functional programming.' »

I won’t try to define functional programming, and I certainly won’t enter the unproductive feuds over whether certain languages are « pure functional » or « as functional as mine is. »

Essentially, the mantra of functional programming is « no side effects. » Other languages allow you to alter the values of variables inside of functions, and even to define global variables outside any function. In functional programming, by contrast, each function has no impact except to return a value to be used for further calculations. Simon Peyton Jones, who has worked on the Haskell compiler (the Glasgow Haskell Compiler) for many years, defines the effect this way: « In functional programming (as in mathematics) a variable names a value. In imperative programming, a variable names a mutable cell whose value is then changed over time. »

In practical terms, the functional model introduces two key concepts: immutable variables and asynchronous communication. When a compiler knows that a variable will not be changed, it can schedule calculations much faster. Asynchronous communication facilitates concurrency by eliminating locks and barriers.

In contrast, imperative languages depend on mutable variables. Functions indicate the state of the system—a form of communication between functions—by changing variables.

(To learn about the far-reaching uses of immutability in storage and elsewhere, check out a classic article from ACM Queue.)

Of course, every functional program has to bend the « no side effects » rule in order to output its results to the user or create some effect on the outside world. The program will eventually write to a file or send a packet over a network. But functional programming—particulary in Haskell’s IO system and Erlang’s I/O protocol—strictly separates operations with side effects from those without. Most functions can remain pure, without side effects that are noticeable to the world. Functional languages could be compared to The Who’s Tommy: the deaf, dumb, and blind boy who plays a mean pinball.

Wallflowers at the Dance

It’s hard to get information on the popularity of functional languages over the past few decades. The TIOBE index prints long-range statistics for just ten languages that were popular over the years—and that leaves out the languages in this article. The Redmonk Language Rankings, covering the past 14 years, mention only Scala.

We can check current popularity in ZDNET’s 2024 « programming language popularity index » (where none of the languages in this series appear), in IEEE Spectrum, or in Statista’s « Most used programming languages among developers worldwide as of 2025. »

For the sake of comparison, several arguably obsolete languages (Visual Basic, Fortran, and Ada) rank higher than the languages in this series, no doubt because they have substantial installed bases.

But popularity isn’t a fair measure of the value of a language. JavaScript and languages based on it, such as TypeScript, will obviously be popular because they were designed to display web pages. A language of limited popularity could be very valuable for a niche setting.

Let’s look at a few specific languages.

Scala

Scala has reached more people than the other languages in this series. That’s because, like several other languages introduced around that period (Kotlin, Clojure, and Groovy) Scala compiles to bytecode that runs on the Java Virtual Machine. And because it shares the JVM with Java, Scala programmers can easily integrate the huge number of Java libraries that have built up over the decades into their programs. My contacts say that Scala has peaked, although it appears to keep up its popularity in the Redmonk Language Rankings mentioned earlier.

Dean Wampler, author of Programming Scala, says that Scala started as a “research language” (as did Haskell). Scala’s maintainers, therefore, sometimes break backward compatibility as they make improvements—something that maintainers of highly popular languages strive not to do.

Wampler explains that Scala appealed at first to people frustrated by Java’s verbosity and heavyweight syntax. He told me that when Scala was introduced, “Java had gotten moribund. In Scala, you could define in one line a class that might take 20 lines in Java.” It was “mind-blowing” how much more compact the code could be than in Java. So Scala isn’t as important as it used to be since Java 8 adopted lambda expressions and other functional concepts.

Now Scala’s use is limited to “language enthusiasts.” Wampler points out that, with the increasing availability of rich code libraries—noting his own field in particular, artificial intelligence—people don’t need a language that allows them to write a lot of powerful code, but just a simple glue language such as Python.

The people I interviewed for this series aren’t concerned with the relatively small numbers of people using their languages, and even take it as a badge of pride. Not everyone has the discipline to learn a functional language—I’ll return to that idea at the end of the series.

Haskell

Peyton Jones also sees Haskell as a « laboratory » and says the developers are willing to break backward compatibility. So long as the Haskell community is tight-knit, the developers of the language can remain « nimble. » « In the laboratory spirit, » Peyton Jones writes, « backward-compatibility is not an absolute, and the community sometimes agrees on changes that improve the language in a non-compatible way. As Haskell has become more widely adopted, the Haskell community has paid more and more attention to backward compatibility. » But he expects that the language will continue its historic role as the source of innovations that spread throughout the computer field.

Although I won’t argue about how « purely functional » any language is, operations in Haskell are certainly under careful control. The language’s strong conceptual structure allows for advanced features such as transactional memory, which Peyton Jones developed. Transactional memory not only provides atomicity to multiple operations in a program, but allows threads to wait on each other without mutexes and all their associated risks. Peyton Jones said that the feature is so valuable that Microsoft tried to add it to .NET, but had to give up because imperative languages lack Haskell’s control over changes to variables.

Another advanced feature in Haskell is generalized algebraic data types, an extension of type classes. GADTs, along with many other advances in functional programming, depend on its sophisticated type system.

Erlang

Cesarini was the first to offer me the historical background for this series, explaining that functional languages might not be popular because they have become less necessary as their valuable ideas enter other languages.

Many people including Cesarini are using Elixir, a relatively recent programming language that runs on the Erlang virtual machine. A lot of innovation surrounds Elixir: Cesarini points to its Web framework, Phoenix, which he calls « Ruby on Rails for the twenty-first century »; Numerical Elixir, a framework supporting AI; and the Nerves project for embedded systems.

In the second and final article of this series, we’ll see how imperative languages have syncretically taken on concepts from functional languages—but not the core of functional programming itself. I’ll also offer a viewpoint about the future of programming.