In this edition:

• Graham explains the benefits of solving problems with a functional mindset.
• Adrian explores why functional programming was shunned until it was not.
• In our Vidéothèque section, we watch Joe Armstrong explain how functional programming made Erlang a reality.
• In the Library section, we review the most important papers by Philip Wadler, Guy Steele, and Gerry Sussman.

Download this issue in DRM-free PDF or EPUB format, and read it on your preferred device. You can also subscribe to our RSS feed, featuring the full content of our articles.

We would like to thank our patrons who generously contribute every month (or have contributed in the past) to our work and help us run this magazine. Thank you so much! In alphabetical order: Adam Guest, Adrian Tineo Cabello, Benjamin Sheldon, Christopher Nascone, Colin Powell, Franz Lucien Moersdorf, Guillermo Ramos Álvarez, Jean-Paul de Vooght, Dr. Juande Santander-Vela, Patryk Matuszewski, Paul Hudson, Quico Moya, Roger Turner, Szymon Licau, and countless more leaving anonymous tips every month.

Enjoy this issue! Please share our articles on social media, or contribute if you would like to support our work with a donation via Liberapay.

Cover photo by Milad Fakurian on Unsplash.

Take object-oriented programming, for example. Selecting Java as an implementation language does not immediately mean that your solution is object-oriented (though it may have been sufficient to get you some OOP-linked venture capital at the peak of the hype cycle). Similarly, when you see an implementation language that does not have object features, FORTRAN-77 for example, that does not mean that you are not looking at the source code of software built using the object-oriented paradigm.

But this is the issue on functional programming, not OOP. The paradigmatic basis of functional programming is that you design your program as algebraic transformations of structured data types. This affects how you discuss your program with stakeholders, how you model requirements, how you architect solutions and deployment…it is not just a matter of reaching for Haskell (indeed using the do form it is very easy to write procedural software in Haskell anyway).

You compose large programs by combining algebraic transformations into more complex operations. As such, you define transformations that are composable. This composability comes from designing transformations with clear contracts and interfaces, so that the result of applying the transformation is evident and safe in the context of the composition. For example, imagine that you have a need to double every element in a list of numbers. It is easy in many imperative languages to write a loop that iterates over the list and multiplies each number by 2. But thinking about this “problem” using the paradigm of composing algebraic transformations, you can build the solution from two components:

1. Apply an operation to every element of a list.
2. Multiply a number by 2.

So now you can build two functions, which are demonstrated as procedures written in Pascal here because, as I said, tool use is not paradigmatic; and besides, Pascal and Haskell nearly rhyme and both languages are named after mathematicians, so they are almost the same thing. The first function to create is the Map function, which applies a function to every element in a collection and returns a collection of the results:

unit Functional;

interface

type
  generic TArrayU<U> = array of U;
  generic TMapFunc<T, U> = function(const Item: T): U;

generic function Map<T, U>(const Arr: array of T; Func:
    specialize TMapFunc<T, U>):
    specialize TArrayU<U>;

implementation

generic function Map<T, U>(const Arr: array of T; Func:
    specialize TMapFunc<T, U>):
    specialize TArrayU<U>;
var
  i: Integer;
begin
  Result := nil;
  SetLength(Result, Length(Arr));
  for i := 0 to High(Arr) do
    Result[i] := Func(Arr[i]);
end;
end.

The generic interface for the Map function means that even if you did not look at the implementation, you would know something about how it works. Its inputs are an array of T, and a function that turns T into U, and its output is an array of U. Nowhere is anything specified about T or U. That means that the function cannot use any of the operations available on either T or U, so if there is a U in the output the only way that Map created it was by applying the function to one of the Ts in its input.

Unfortunately Pascal arrays have a rich interface so it is impossible to say anything about which Ts get turned into Us; the function might always return nil, for example. The implementation shows that this Pascal Map works as you might expect a map function; it applies the Func parameter to each T in the input array, and returns an array where the corresponding U is at the same index as the given T.

The second function you create is the DoubleInt function that multiples a number by 2 and returns the result:

function DoubleInt(const i: Integer): Integer;
begin
  Result := i * 2;
end;

Here the interface does not help much at all: the input is an Integer, and the result is an Integer. The function might always return a constant, or square the input, or add it to a constant, or convert it into a String, reverse the characters, and convert that back into an Integer to return. This demonstrates the power of generic component design: the less information available about the types used in a function, the more constraints on the behavior of that function, so the easier that function is to understand.

Now you solve the problem by composing DoubleInt and Map:

program Main;

uses
  Functional, SysUtils;

type
  TIntArray = array of Integer;

var
  Ints, Doubled: TIntArray;

begin
  Ints := TIntArray.Create(1, 2, 3, 4, 5);

  Write('Original: ');
  for i in Ints do Write(i, ' ');
  WriteLn;

  Doubled := specialize Map<Integer, Integer>(Ints, @DoubleInt);
  Write('Mapped (Double): ');
  for i in Doubled do Write(i, ' ');
  WriteLn;
end.

These two functions are very simple mappings of their input to their output. You could imagine implementing DoubleInt as a lookup table, where the value at index 0 is 0, the value at index 1 is 2, and so on. In principle you could do the same for Map but it would be a very tedious table to write, and it would lose the simplicity of using the Func parameter to achieve the transformation.

A problem for composability arises when you want to use a program to do something; to store or retrieve a result, or to interact with its environment. These kinds of computations do not show up in the function signature, so you cannot tell the difference between “function that accepts a list of T and returns a Boolean” and “function that accepts a list of T, drops all tables in the database, and returns a Boolean”. It is harder to build functions into reusable workflows when they might have side effects like that.

A solution used by people who think in the functional way is monads, a class of types that associate values with context and enables computations on the values while maintaining the association with the context. Again, because there is nothing special about programming language choice, you can build that in Pascal:

unit Monads;

interface

type
  generic IMonad<T> = interface
    ['{7A8D8C30-5A2C-4B9F-8F8D-9E9C9B9A9D9E}']
    function Execute: T;
  end;

  generic TIOReturn<T> = class(TInterfacedObject, specialize IMonad<T>)
  private
    FVal: T;
  public
    constructor Create(const V: T);
    function Execute: T;
  end;

  generic TIOBind<A, B> = class(TInterfacedObject, specialize IMonad<B>)
  public
    type
      TBF = function(const V: A): specialize IMonad<B>;
  private
    FPrev: specialize IMonad<A>;
    FFunc: TBF;
  public
    constructor Create(const P: specialize IMonad<A>; const F: TBF);
    function Execute: B;
  end;

implementation
{...}
end.

All this makes it look like there is nothing to a “functional programming language” other than the convenience of expressing paradigmatic functional thinking efficiently. For example, if you had access to a programming language that is like Pascal but also has partial application (function currying, to use Haskell Curry’s family name) then you could create the DoubleInt function in the first example above by applying 2 to the Multiply function, and avoid needing to write a custom component for such a simple operation.

Using the idea that all computationally universal models are equally powerful, you can do your functional thinking in your brain and then convert it into Haskell, Pascal, or even languages that do not rhyme and are not named after mathematicians. This statement, true as it goes, is not helpful. Functional programming as a style does benefit from specifically designed programming languages, that perform for software engineering what John Locke achieved for national goverment in the 17th Century: the separation of [Alonzo] Church and state.

The Pascal functions above might present interfaces that represent composable algebraic primitives, but under the hood their implementations are sequential applications of state transitions in a slightly abstracted version of the computer’s memory. Pascal’s model of computation might let it reorder some instructions a little, but fundamentally it, and similar languages like Algol, C, Rust, and Python, are there to make it easy for you to sequence changes to the computer’s memory.

A goal of functional programming is to escape the von Neumann bottleneck, describing programs in ways that are not limited by the sequencing of changes to memory states. Yes, that has to happen, but it does not have to be the programmer’s responsibility. Instead, the programmer’s task is to explain what the program should do, and the computer’s task is to find an efficient way to do it. Tail-call recursion, lazy or applicative evaluation, memoization, parallelism—none of those are your problem.

The most widespread examples of programming tools that embody this notion of communicating intent, not computation, are query languages (and these days, coding AIs). You do not tell SQL, or LINQ, how to loop over the elements in a collection; you tell it which properties you want from what elements (for example, composing primitives expressed in the Relational Algebra like “Select” and “Project”), and the computer works out an efficient way to make that happen.

You can reap the benefits of functional thinking in whatever programming language you happen to use. To truly escape the clutches of von Neumann and take advantage of functional computation, you do in fact need to choose your tools wisely.

Horrific disestablishment pun by Prof. Jeremy Gibbons. Photo by Sanket Shah on Unsplash.

“Modern” programming languages include, almost without exception, features borrowed from the realm of functional programming languages. This can be briefly summarized as follows: “lambdas” or “closures” that can be passed around and called a piacere; a series of functions to manipulate arrays called map(), filter(), and reduce() (provided either as standalone functions or as methods of some Array class provided by the languages’ runtime libraries); immutable records or classes, guaranteed to be unchanged throughout the execution of the program; and sometimes even a “pipe operator” looking like this: |>.

In the latter case, we can include the humble PHP programming language, which features such a contraption since version 8.5, released last November at the time of this writing. Which means that the two statements below produce similar results:

$result1 = trim(str_shuffle(strtoupper("hello")));
$result2 = strtoupper("hello") |> 'str_shuffle' |> trim(...);

Spoiler alert: the ellipsis (since PHP 8.1) makes a closure out of a pre-existing function, but as shown above, you can just use a string with the name of the function you would like to “pipe” your output into. Oh, and beware of the fact that array_map() takes the callback function as the first argument rather than the second, which means that… you need a wrapper to invert the arguments. Yeah, as one author describes the current situation in PHP,

The deeper issue is the stdlib itself. PHP’s stdlib was never shaped for chaining. array_map and array_filter taking arguments in different orders is a 1995 design that calcified before anyone thought about composition. The pipe operator works around the symptom. Native methods on arrays and strings would fix the cause.

(Takes a deep breath.)

Other than such small shenanigans, and thanks to the introduction of the pipe operator, recently laid-off developers coming from the F#, Elixir, OCaml, Elm, or Julia galaxies should now feel at home with PHP (well, almost). Note to Haskell developers struggling to pay rent and willing to jump on the very lucrative market of PHP: in your case the pipe operator looks like an &. You have been warned. Oh, and JavaScript developers will have to wait for their own pipe operator, but it might happen sooner than expected.

Let us be even more radical: according to Kevlin Henney, Excel is the world’s most popular functional programming language, and even better, it now comes bundled with a LAMBDA() function. How about that?

Are these features enough to make PHP (or Excel) a real functional programming language? Let us recap. Closures? Check. Map, filter, and reduce functions? Check. Readonly classes? Check. Pipe operator? As we have seen above, check.

But of course, no, PHP is not really a pure functional programming language. It still allows for side effects, and that is a big no-no-no in that world. Even worse, it is quite obviously a procedural language, not really a declarative one. But with a little bit of attention, and maybe with the help of your preferred LLM-powered IDE and some unit tests, your PHP code can reach levels of “functional compliance” Rasmus Lerdorf could only dream of (well, perhaps he never dreamt of such a thing; I give you that).

The real question is the following: why does a parochial programming language such as PHP now include these features? The reasons behind the choice to add them as part of the specification have a strong element of hype.

The jump to concurrency and the economics of cloud computing have given functional programming constructs a boost that neither desktop nor mainframe applications ever could. Let us be honest here: in the world of concurrency, multicore CPUs, at the end of the “free lunch” world, functional languages shine.

The trend was apparent at the beginning of the 2000s, and it simply exploded during the 2010s. Scala was released in 2004, becoming the first functional programming language built on top of the JVM; standard Java developers would have to wait until Java 8 (released in 2014) to be able to write code including lambda expressions and its associated map, filter, and reduce functions. On the other side, the C# community discovered LINQ in 2005 already, effectively transforming array manipulation into a SQL-like contraption. In the galaxy of Apple, Objective-C blocks and their associated arcane syntax appeared together with Grand Central Dispatch around 2009. C++ debuted lambda expressions in its specification in 2011.

Languages created in the past 20 years almost inevitably include one or another of the functional programming features enumerated above: Go functions are first-class objects. TypeScript builds on top of the already existing JavaScript language. Rust closures come in various “traits” depending on how they capture their surrounding environment. Elixir brought closures on top of the Erlang BEAM. Dart has supported closures since its first version. F# brought rather pure functional programming features to the .NET runtime. Swift had first-class functions from day one, and for a while, even object-oriented methods were implemented as closures. Finally, Kotlin brought a shorter, simpler syntax for closures on top of the JVM.

Oh, and then PHP followed the trend, obviously. By the way, it is worth mentioning that Python, Perl, and Lua have had support for lambdas since the 1990s, at a time when these concepts were still considered fringe.

Undeniably, in the same vein, the rise in popularity of Python, Ruby, and JavaScript during the past two decades also contributed to the slow march of functional thinking into the minds of software developers worldwide. Speaking (again) about JavaScript, we have talked about Douglas Crockford’s magnum opus in a previous article of this magazine, and it was obvious to him that one of the “good” parts of JavaScript was, precisely, its functional programming roots:

JavaScript is built on some very good ideas and a few very bad ones.

The very good ideas include functions, loose typing, dynamic objects, and an expressive object literal notation. The bad ideas include a programming model based on global variables.

JavaScript’s functions are first class objects with (mostly) lexical scoping. JavaScript is the first lambda language to go mainstream. Deep down, JavaScript has more in common with Lisp and Scheme than with Java. It is Lisp in C’s clothing. This makes JavaScript a remarkably powerful language.

The quote above explains why, at the time of this writing, the latest version of the quintessential book on functional programming, “Structure and Interpretation of Computer Programs”, by Abelson and Sussman, is the “JavaScript Edition”. The choice of JavaScript somehow gives reason to Philip Wadler, who in 1987 argued that using Scheme was probably not the best idea to begin with.

Lisp would certainly deserve a whole issue of this magazine, but chapter 5 of Waldrop’s “The Dream Machine”, a book we reviewed precisely a year ago, contains a beautiful description of its early history and its impact:

Nonetheless, it’s fair to say that one of Lisp’s two greatest legacies to the art of programming was a certain style, a certain exploratory approach to pushing back the software frontiers.

And the other legacy? An undeniable grace, beauty, and power. As a Lisp programmer contined to link simpler functions in to more complex ones, he or she would eventually reach a point inwhere the whole program was a function–which, of course, would also be just another list. So to execute that program, the programmer would simply give a command for the list to evaluate itself in the context of all the definitions that had gone before. And in a truly spectacular exercise in self-reference, it would do precisely that. In effect, such a list provided the purest possible embodiment of John von Neumann’s original conception of a stored program: it was both data and executable code, at one and the same time.

Since its presentation in a now legendary paper by John McCarthy, Lisp’s power and beauty have often been mentioned by pundits and entrepreneurs alike. In the latter group, we cannot avoid mentioning Paul Graham: his 2001 article “Beating the Averages” tells the story of his 1995 e-commerce startup “Viaweb”, built in Lisp, a language he deeply loved. That article also makes a surprising connection between Lisp and the (badly named) “Sapir-Whorf hypothesis” of linguistic relativity:

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.

Paul Graham was not the first to make the connection to the Sapir-Whorf hypothesis, by the way: Kenneth Iverson, creator of the APL programming language, also explained this during his 1980 Turing Award lecture, “Notation as a Tool of Thought” as follows:

Concerning language, George Boole in his Laws of Thought asserted “That language is an instrument of human reason,, and not merely a medium for the expression of thought, is a truth generally admitted.”

Mathematical notation provides perhaps the best-known and best-developed example of language used consciously as a tool of thought.

Those of us brave enough to have written code in APL can only agree that its notation brings a whole new meaning to the word “programming”.

So it was that, standing on the shoulder of this giant called Lisp, people came up with projects ranging from Medley Interlisp to a Lisp interpreter built as Conway’s Game of Life.

Lisp, and later functional programming languages, have enlightened software programmers to go above and beyond what commercial offerings could even dream of. They have stretched our thinking, opening doors to concurrency, mathematical breakthroughs, early artificial intelligence efforts, and the widest possible array of scientific exploration about computation.

Yet, already in the 1990s it was apparent that Lisp (and, to a large extent, functional programming) was at risk of being relegated or even of becoming extinct, and today some influencers ask themselves, where did all the functional programmers go? The answer is simple: they are all among us; we are all, to a small or large degree, better software engineers because there has been a healthy breeding process between procedural, object-oriented, and functional programming languages that begat modern tools for a modern world.

All things considered, the most important contribution of functional languages in the modern world was a certain way of thinking about programming, more than just actually adopting “pure” functional compilers in our day-to-day jobs. Put in other words, mastering functional programming concepts fundamentally transformed the way we create software. And in the best possible way.

Cover photo by Pablo Martinez on Unsplash.

That is why we have chosen as this month’s Vidéothèque choice his presentation titled “Systems that run forever self-heal and scale” at the 2013 Lambda Jam, a conference that featured an impressive schedule with talks by Ola Bini, Chris Ford, Dave Thomas (not the Pragmatic Dave), Bartosz Milewski, Adam Granicz, Steve Vinoski, and Gerald Jay Sussman.

As you most probably know by now, Joe Armstrong (1950-2019) is mostly known for his work on Erlang, a massively concurrent and functional programming language, coupled with BEAM, the virtual machine that enabled telcos, starting in the 1990s, to serve millions of users with complex systems in the most efficient and resilient way.

Kids, this was 20 years before Go or Kubernetes were even conceived. Erlang enabled companies to scale their services in ways that were unthinkable even by today’s standards, running on hardware way underpowered compared to that of our modern world of 2026.

Joe kicked off his acclaimed book “Programming Erlang” (released in 2007 by The Pragmatic Programmers, with a second edition published in 2013) with a clear disclaimer:

In many places we’ll be extolling the virtues of functional programming. Functional programming forbids code with side effects. Side effects and concurrency don’t mix. You can have sequential code with side effects, or you can have code and concurrency that is free from side effects. You have to choose. There is no middle way.

And he goes on to explain on page 44 (mind you, this was written in 2007) what “functional” means in this context:

Erlang is a functional programming language. Among other things this means that funs can be used as arguments to functions and that functions (or funs) can return funs.

Functions that return funs, or functions that can accept funs as their arguments, are called higher-order functions. We’ll see a few examples of these in the next sections.

I stress the fact that this was written in 2007 because merely 20 years ago, as we were entering the “plateau of productivity” in the hype cycle of Object-Oriented Programming, we were also witnessing how Twitter (the original name of a decadent social network still active as this article hits the press) was suffering with “fail whales” shown on its home page, while millions of users were trying to read the tweets on their (not yet algorithm-driven) feeds. The time was ripe for a new paradigm… but apparently, unbeknownst to the Twitter team, it already existed.

Interestingly, the WhatsApp developer team knew exactly that they needed something else to create a system potentially usable by billions of simultaneous users, so they chose Erlang, and boy did that work well. More on that later.

In his 2013 conference talk, Joe Armstrong started with some simple observations: the real world is parallel. Boom. It turns out that Erlang processes are the perfect way to model such a world: they can be thought of as a group of people communicating by message passing.

Let us remember what Alan Kay said about messaging in 1998:

The big idea is “messaging” – that is what the kernal of Smalltalk/Squeak is all about (and it’s something that was never quite completed in our Xerox PARC phase). The Japanese have a small word – ma – for “that which is in between” – perhaps the nearest English equivalent is “interstitial”. The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.

So here we have a programming language that allows you to model a world with certain characteristics that Joe describes around minute 05:30: many computers distributed all over the place, working concurrently, detecting their own failures and repairing them as soon as possible, and even featuring a radical concept called live code upgrades.

Sounds familiar? Any parallels with Kubernetes are just a coincidence. In Erlang, there is no such thing as an atomic update of the “stop it, upgrade, restart” kind (06:50): Erlang applications are continuously partially upgrading themselves whenever needed.

Needless to say, this was beyond impressive in the mid-1990s, but Sun had a bigger marketing budget than Ericsson. Insert sad face emoticon here.

Erlang was designed from the ground up for “5 nines reliability” (07:10) because of a simple observation: it is much better to design a system for 10 million users and scale it down to 10,000 than to scale it up from 10 to 10,000. The result is that by 2013 there was a 50% chance that smartphones went through Erlang to talk to the mobile Internet.

But Erlang is just a piece of the whole architectural cake, albeit a critical one. Joe goes on to elaborate on the patterns required for system consistency and fault tolerance, distributed consensus (23:36), and the evolution from Lamport’s Paxos to Ongaro’s and Ousterhout’s Raft. He also mentions six rules for fault tolerance (30:00), applicable to any massively distributed system running on your nearest Kubernetes cluster nowadays: process isolation, concurrency, failure detection, fault identification, live code upgrade, and stable storage.

Legendary computer scientist Jim Gray wrote a widely quoted paper in 1986 titled “Why Do Computers Stop and What Can Be Done About It?” where he said:

The top priority for improving system availability is to reduce administrative mistakes by making self-configured systems with minimal maintenance and minimal operator interaction.
(…)
As with hardware, the key to software fault-tolerance is to hierarchically decompose large systems into modules, each module being a unit of service and a unit of failure. A failure of a module does not propagate beyond the module.

Now you understand why your Kubernetes Deployment YAML contains a readiness and a liveness probe, for example. You are welcome.

Towards minute 46 of the video, Joe goes on to talk about Erlang in detail, enumerating some success stories: Mnesia, CouchDB, Riak, ejabberd, RabbitMQ, and, yes, of course, WhatsApp, snapped up by Facebook for a hefty 20 billion dollars of pocket money. And then he goes on to discuss the future of Erlang as seen from the perspective of 2013: Elixir, a programming language based on BEAM and OTP but offering an admittedly much friendlier syntax (inspired by Ruby) with interesting metaprogramming possibilities.

Watch this month’s Vidéothèque entry, “Systems that run forever self-heal and scale,” by Joe Armstrong, on YouTube. Continue binge-watching “Erlang: The Movie,” a 1990 short nowadays available on YouTube and the Internet Archive, showing a demo of a bug-fixing session on a live Erlang system. Let us repeat for the people in the back: 1990.

Cover snapshot chosen by the author.

That world that you just imagined? We live in it. Meet Guy L. Steele, Jr., and Gerald J. Sussman, two of the luminary thinkers from the Massachusettes Institute of Technology Artificial Intelligence Lab. This is the first go around the AI hype cycle, back when computers were routinely called thinking machines but before people even pretended that computers were doing any thinking.

However, it is really not that valuable to distinguish between AI computing and non-AI computing, because all computation is an emulation of intelligence. The AI research community is best thought of as an advanced computational techniques community that began life exploring computational methods to understand thought, and that is where this story begins. The person who coined the phrase “Artificial Intelligence” was John McCarthy, and for no more highbrow reason than that he thought if he presented his work in symbolic computation techniques as “cybernetics” then he would end up having an argument with Norbert Weiner, and if he called it “information processing” then the argument would be with Claude Shannon. Both of these intellectual giants were too scary to argue with.

McCarthy consulted for IBM on the addition of a List Processing library to FORTRAN, but preferred to use an algebra based on symbolic expressions so created his own programming language, LISP. For the first few years LISP users had to execute their programs by hand using pencil and paper, until Steve Russell noticed a huge opportunity. The language includes a neat trick called eval which interprets a LISP expression as a LISP program, and Russell realised he could implement eval in machine language (by punching holes into punchcards) on the IBM 704. Thus is was, with the creator of LISP and the creator of AI research being the same person, that LISP became the preferred programming language of AI researchers.

Fast-forward to the mid-1970s, and the MIT AI Lab (counting McCarthy among its alumni, of course) used a LISP dialect called Maclisp: nothing to do with the later personal computer model, but named after the Project on Mathematics And Computation that hired the original AI group (including McCarthy, of course). Maclisp’s innovation over LISP is the use of value cells to associate objects with symbols, where LISP maintained a list of associations that it scanned through to find the object. Two of the AI lab members—the heroes of this story—wanted to explore the Actor model of computation (another product of the AI research galaxy), and did so in their own, minimalist LISP interpreter, which they wrote (inevitably) in Maclisp.

They borrowed a neat idea from the ALGOL programming language: block structure, and lexical scope. A variable (or function, or label) can be declared inside a block, in which case it is local to the block: it only exists while that block’s in scope. If the variable has the same name as an existing variable from another scope, it shadows that variable, replacing uses of variables of that shared name with itself. But only within the block.

Steele and Sussman documented this Lisp interpreter, which they called Scheme, through a series of AI Memos now sometimes called the LAMBDA papers, after the recurring form “LAMBDA: the Ultimate X” in their titles. In LAMBDA: the Ultimate Imperative, they show that lambda application can model almost every feature of an imperative language (using ALGOL in their case, but the same would apply to FORTRAN, C, Swift, Rust, or your favourite poison). Steele then issued a correction a few months later, LAMBDA: the Ultimate Declarative.

Whoops! Did we say that lambda was the ultimate imperative? What we meant was that function calling is the ultimate imperative if you think of a function call as a GO TO statement with a message alongside it (sending messages? That is the actor model achieved!); what lambda gives you is a way to rename variables, defining an environment in which your fancy GO TO operates. That is a powerful idea in itself, because it means you do not have to mess around copying values into registers or onto the stack whenever you call a function; you just associate the new name with the existing value. He further explored this idea in Lambda: the Ultimate GOTO.

Eventually, in 1979, the two authors published LAMBDA: the Ultimate Opcode, in which they design the LISP machine: a hardware implementation of a state machine that evaluates LISP expressions, along with operations that work efficiently with the linked data structures native to the language.

Reading this series of AI memos in 2026, which are written in a straightforward, tutorial style, gives one first the feeling that understanding the complexity of computers and programming languages might not be so difficult, after all. Then, one remembers that their current problem involves multiple programming languages and script files and YAML files and TOML files, and the effect is more like being Charlton Heston looking up at the Statue of Liberty.

Cover photo by the author.

The source of the confusion is none other than an excerpt of a masterpiece often quoted in the pages of this magazine: James Iry’s 2009 brilliant “A Brief, Incomplete, and Mostly Wrong History of Programming Languages”:

1990 - A committee formed by Simon Peyton-Jones, Paul Hudak, Philip Wadler, Ashton Kutcher, and People for the Ethical Treatment of Animals creates Haskell, a pure, non-strict, functional language. Haskell gets some resistance due to the complexity of using monads to control side effects. Wadler tries to appease critics by explaining that “a monad is a monoid in the category of endofunctors, what’s the problem?”

The jury is still out debating the role that Ashton Kutcher had in the creation of Haskell, but as usual, I digress.

What is important to consider is that, yes, Philip Wadler might as well have coined the “endofunctors” meme; after all, he has singlehandedly done more to popularize and to extend the usage of functional programming languages than anyone else in the history of computing. And he has even coined the term “list comprehension”, which might ring a bell among Python developers, among others.

On the other hand, monads are a relatively recent addition to the arsenal of functional programmers; Italian computer science professor Eugenio Moggi was the first to describe the use of monads in programming in two papers published between 1989 and 1991. Philip Wadler took the idea, bolted it down into Haskell, James Iry wrote his blog post, and the Internet did the rest.

I am kidding; Wadler did more than just take the idea: he helped everyone comprehend how monads could be used to marry the “impure” necessities of actual programming with the “pure” realm of functional programming:

Purity has its regrets, and all programmers in pure functional languages will recall some moment when an impure feature has tempted them. For instance, if a counter is required to generate unique names, then an assignable variable seems just the ticket. In such cases it is always possible to mimic the required impure feature by straightforward though tedious means. For instance, a counter can be simulated by modifying the relevant functions to accept an additional parameter (the counter’s current value) and return an additional result (the counter’s updated value).

A quick search shows that Mr. Wadler had a strong interest in such a marriage early on; case in point, his 1985 paper “How to replace failure by a list of successes: a method for exception handling, backtracking, and pattern matching in lazy functional languages” where he argues that

The method itself is straightforward. Each term that may raise an exception or backtrack is replaced by a term that returns a list of values.

Mr. Wadler went above and beyond, explaining that monads were “the essence of functional programming” (1992) and then using them to perform input/output in a pure functional way in the widely acclaimed 1993 paper “Imperative functional programming” (winner of the 2003 ACM SIGPLAN Most Influential POPL Paper Award):

We need a way to reconcile being with doing: an expression in a functional language denotes a value, while an I/O command should perform an action. We integrate these worlds by providing a type IO a denoting actions that, when performed, may do some I/O and then return a value of type a.

Speaking about “monads” and “functions” and whatnot, the astute reader will remark that mostly everything that has to do with functional programming is related, eventually, to some obscure mathematical theory most self-taught software developers (like the one writing these words) have never heard about, created by a long list of mathematicians including Peano, Cantor, Russell, and Gödel.

And let us not forget the list of functional programming languages whose names derive from mathematicians: Haskell, Curry, Church, Gödel, Russell, Frege, Rocq (originally named “Coq” after French mathematician Thierry Coquand), Kleenex (named after American mathematician Stephen Cole Kleene), and Erlang. Honorific mentions of the non-functional languages Euler, Pascal, Napier88, occam, Z notation (whose name derives from Ernst Zermelo), and Ada are definitely worth mentioning.

Wait, what is Russell’s name doing in the previous lists? Well, according to a 2003 paper by Kevin Klement, from the University of Massachusetts, unpublished papers from Russell suggest that he did much more than just suggest the notation that Alonzo Church used for lambda calculus. But we leave this bit to the reader to explore.

A certain D. A. Turner, from the University of Kent & Middlesex University, wrote in “Some History of Functional Programming Languages” (2013) that the lineage of functional programming starts in the 1930s with Church & Rosser’s Lambda Calculus (a very mathematical theory of computation), then flows through McCarthy’s LISP, Algol 60 (believe it or not), and Gordon & Milner’s ML, culminating in the creation of Haskell from 1987 onwards:

In what follows I have, firstly, focussed on the developments leading to lazy, higher order, polymorphically typed, purely functional programming languages of which Haskell is the best known current example.

Would we be too picky to argue that Mr. Turner forgot to include John Backus, of FORTRAN and ALGOL fame, who in his 1977 Turing Award lecture proposed functional programming as a viable alternative to the Von Neumann programming model?

In this section we give an informal description of a class of simple applicative programming systems called functional programming (FP) systems, in which “programs” are simply functions without variables. The description is followed by some examples and by a discussion of various properties of FP systems.

Philip Wadler is a member of the original committee behind Haskell, probably the most successful exception in the world of committee-created things. Not only that, he also co-created this thing called XQuery (which you might have used 20 years ago to parse some XML, a format not so much en vogue these days) and was also heavily involved in bolting generics on top of Java 5 (a language and a feature that, yes, you might have had a much higher probability of using).

Haskell enjoys quite a level of popularity in our century, similar to that of Lisp in previous decades. Even Edsger Dijkstra defended it in 2001, when a group at the University of Austin, Texas, decided to replace Haskell with Java in the introductory programming course:

A very practical reason for preferring functional programming in a freshman course is that most students already have a certain familiarity with imperative programming. Facing them with the novelty of functional programming immediately drives home the message that there is more to programming than they thought.

But again, Haskell is a subject in itself, and I cannot help but digress once again.

As explained in the “Frequently Asked Questions for comp.lang.functional” page, Philip Wadler collaborated in 1997 with a certain Martin Odersky to create “Pizza”, a functional superset of Java… any similarities with Scala are, I suppose, just a coincidence.

Oh, and Mr. Wadler is a prolific writer of research papers and books, among which stand out the chapters he contributed to “The Implementation of Functional Programming Languages” (1987) by his aforementioned partner in crime, Simon Peyton-Jones (and available for free on the Microsoft Research website at the time of this writing). Also notable is “Introduction to Functional Programming” (1988), co-authored with Richard Bird and renamed “Introduction to Functional Programming using Haskell” for its second edition published in 1998.

Among his most famous papers, let us mention “Theorems for Free!” (1989), “Call-by-Value is Dual to Call-by-Name” (2003), “The essence of functional programming” (1992), and “A History of Haskell: Being Lazy With Class” (2007), the latter being a very appropriate entry for the upcoming HOPL V conference in 2035. Furthermore, a full-text search for his family name on the Journal of Functional Programming (of which Wadler was editor from 1990 to 2004) returns a staggering 421 entries at the time of this writing.

All this record of writing and conference talks is quite opinionated. Philip Wadler has made his life’s mission to show that functional programming languages could be used in the real world as a counterstrike against the overwhelming marketing campaigns around those languages that are not. In his “An Angry Half-Dozen” paper (1998), he describes 6 major technological wonders brought to life thanks to functional programming, and one of them is Erlang:

Erlang bears a striking resemblance to another modern phenomenon, Java. Like Java, Erlang (along with all other functional languages) uses heap allocation and garbage collection, and ensures safe execution that never corrupts memory. Like Java, Erlang comes with a library that provides functionality independent of a particular operating system. Like Java, Erlang compiles to a virtual machine, ensuring portability across a wide range of architectures. And like Java, Erlang achieved its first success based on interpreters for the virtual machine, with faster compilers coming along later.

That same year, he tried to explain why no one was using functional languages:

If a manager chooses to use a functional language for a project and the project fails, then he or she will certainly be fired. If a manager chooses C++ and the project fails, then he or she has the defense that the same thing has happened to everyone else.

Ouch. The following year he repeated himself, merging the previous two papers into another one called “How enterprises use functional languages, and why they don’t”. Was anybody listening at all?

Philip Wadler has kept a record of every important use of functional programming on his own website since at least 1999, as the Internet Archive can testify, and this effort continues at the time of publication of this article.

However, and rather surprisingly, Pandoc is not mentioned in this list, and yet, it is literally made with Haskell! We are delighted to use Pandoc every month to produce the beautiful (DRM-free, by the way) PDF and EPUB files that you can download from this website.

I hope the core idea of this article is clear. Philip Wadler is a towering figure in the field of functional programming, and the pervasiveness of functional features in most mainstream programming languages nowadays owes a lot to the efforts of this single person.

Haskell is a subject in and of itself, and there have been an incredible number of excellent books written about it in the past two decades. At the risk of leaving aside some obviously outstanding entries, we should mention at least “Real World Haskell” by Bryan O’Sullivan, Don Stewart, and John Goerzen; “Learn You a Haskell for Great Good!” by Miran Lipovača (this one taking more than a few cues from _why’s “Poignant Guide to Ruby”); and the more recent “Haskell Programming from First Principles” by Christopher Allen and Julie Moronuki.

However, if you are just interested in a rather short and high-level overview of the Haskell language, “Seven Languages in Seven Weeks” by Bruce Tate (2010) will give you an excellent starting point for your exploration. Precisely, Chapter 8, dedicated to Haskell, starts like this:

Haskell represents purity and freedom for many functional programming purists. It’s rich and powerful, but the power comes at a price. You can’t eat just a couple of bites. Haskell will force you to eat the whole functional programming burrito.

You have been warned.

To close this article, we feel that the general functional programming literature is so vast, we can only scratch the surface by enumerating some hallmark titles; please do not be offended if your favorite title does not appear on this list:

• “The Implementation of Functional Programming Languages”, by Simon Peyton Jones and Philip Wadler.
• “Introduction to Functional Programming”, by Richard Bird and Philip Wadler.
• “Structure and Interpretation of Computer Programs”, in either edition, in Scheme or in JavaScript, by Harold Abelson and Gerald Jay Sussman.
• “The Genius of Lisp”, a recently released gem by Cees de Groot.
• “Practical Common Lisp”, a classic book by Peter Seibel.
• “Paradigms of Artificial Intelligence Programming”, another historically relevant book by Peter Norvig.
• “Introduction to Lambda Calculus”, a freely available book by Henk Barendregt and Erik Barendsen.
• “From Mathematics to Generic Programming”, by Alexander Stepanov & Daniel Rose.
• “F# for Fun and Profit” and “Domain Modeling Made Functional”, both by Scott Wlaschin.
• “Functional Swift”, by Chris Eidhof, Florian Kugler, and Wouter Swierstra.
• “Scala for the Impatient”, by Cay Horstmann.
• And finally, “Learn Functional Programming the Fast Way!”, by Alvin Alexander, also using Scala to teach concepts.

Cover photo by the author.

In this edition:

• Graham reports on the state of GNU Hurd with very good news.
• Adrian untangles the Linux distro jungle and helps you choose the best one for your needs.
• In our Vidéothèque section, we watch “The Code” by Hannu Puttonen.
• In the Library section, we review “Just for Fun” by Linus Torvalds & David Diamond, and “The Linux Programming Interface” by Michael Kerrisk.

Download this issue in DRM-free PDF or EPUB format, and read it on your preferred device. You can also subscribe to our RSS feed, featuring the full content of our articles.

We would like to thank our patrons who generously contribute every month (or have contributed in the past) to our work and help us run this magazine. Thank you so much! In alphabetical order: Adam Guest, Adrian Tineo Cabello, Benjamin Sheldon, Christopher Nascone, Colin Powell, Franz Lucien Moersdorf, Guillermo Ramos Álvarez, Jean-Paul de Vooght, Dr. Juande Santander-Vela, Patryk Matuszewski, Paul Hudson, Quico Moya, Roger Turner, Szymon Licau, and countless more leaving anonymous tips every month.

Enjoy this issue! Please share our articles on social media, or contribute if you would like to support our work with a donation via Liberapay.

Cover photo by Ian Parker on Unsplash.

Minix uses a microkernel design, in which the kernel is responsible for a limited subset of system services—typically, process scheduling and inter-process communication (IPC) are all that is needed—and everything else runs as a process in “user space”, including device drivers, file systems, and virtual memory managers, in addition to the “applications” that you actually bought the computer to use. The typical alternative is the approach that Torvalds chose for Linux: a monolithic kernel, in which operating system services all run in the kernel, and user space processes provide applications.

Each design has its trade-offs. The kernel is a single, high-privilege space where any code running has very little restriction, so the microkernel approach reduces the “blast radius” of the security risk by strongly restricting the amount of code that runs in the kernel. Because all operating system services happen using IPC, a microkernel can further define the security controls in place in a running system by limiting which processes can communicate with which other processes—and it can do so dynamically, so that a process might be able to make some calls but not others, or make a call at one time that it cannot at another time.

However, all of this IPC comes at a cost, as any system call that an application makes might translate into multiple IPC communications, in which the calling process needs to rewrite its data to fit the interface format of the protocol with the receiving process, then tell the kernel to receive the message, which write the data into the receiving process’s memory space and schedules that process to run. Additionally, microkernel designs run the risk of an “upcall deadlock”, where the kernel cannot make progress because it is waiting on a user-space process that is blocked in a system call. As an example, imagine that an application needs to open a file, and the filesystem process encounters an error that it tries to write to the kernel’s log—which is on the filesystem that encounters the error.

Conversely, the monolithic kernel design makes it easier for any kernel component to directly access any other kernel component: faster, harder to deadlock, but easier to create bugs in and easier to exploit. All those drivers running in the privileged kernel memory space, potentially from multiple vendors or other sources, introduce risks of potentially exploitable problems at the core of the operating system.

Tanenbaum and Torvalds famously had some heated discussions about the relative merits of each architecture, which probably seemed important at the time but are less relevant these days as the microkernel design eventually won out in many contexts (consider mobile phone baseband environments and car management systems, which typically run microkernels like QNX or an L4 derivative), with a hybrid approach (Windows NT is a microkernel design that runs a lot of services in the kernel for performance, and XNU—macOS, iOS etc.—is a microkernel with a monolithic kernel grafted on, but that then runs a lot of secure services in out-of-kernel “exclave” environments) also being popular. At this point, the outlier is the one frequently-observed monolithic kernel design in the wild: Linux.

Anyway, back to that announcement. Torvalds explained that Linux was a hobby project, and “won’t be big and professional like GNU”. Well, these days, Linux is at the core of most operating environments that use GNU software, to the point that they are called “Linux distros” no matter how much some people might like everyone to call them “GNU plus Linux”. So what gives?

The GNU project started in 1984—a full seven years before that Usenet announcement—as a small collection of tools under an umbrella project whose creator’s aim was to offer a full replacement for a UNIX operating system that preserves and promotes the “four freedoms” of free software. Initially, those tools were the GNU Emacs text editor and the GNU C Compiler (later GNU Compiler Collection), both created by project leader Richard M Stallman. During the next few years, people contributed other components to the GNU system and built them in a way that meant they work on many different flavors of UNIX and UNIX-like operating systems, as well as less UNIX-like environments including the Amiga and Windows. However, the whole environment could not be free because there was no GNU kernel (the closest alternative being the BSD kernel, which had licensing restrictions that were interpreted as not freedom-respecting, and which was soon to become embroiled in a lawsuit with the original UNIX creators, AT&T).

The effort to create a kernel, known as Trix, was not close to ready. Eventually the GNU project entered into an agreement with Carnegie-Mellon University to use their Mach kernel (actually in May 1991, after Torvalds had begun work on Linux). Mach is found in operating systems you likely have not used including OSF/1 and NEXTSTEP, and operating systems you may well have used if you have been near the Apple galaxy since about 1997—or earlier, if you are one of the few people who used Tenon’s MachTen or Apple’s MkLinux. Reigniting that debate about monoliths or microkernels, GNU Mach—the GNU project’s own implementation of Mach 3, begun in 1997—operates as a microkernel that loads the Hurd (HIRD of UNIX-Replacing Daemons, where HIRD stands for HURD of Interfaces Representing Depth, where HURD…you get the idea). Immediately snuffing the debate back out, GNU plus Linux is used and useful, where GNU (including the Hurd) has been perpetually “nearly ready” for the intervening decades, including several attempts to replatform the whole system on to a different microkernel (the L4 family of microkernels, Coyotos’ microkernel, and a new project called Viengoos have all been candidates).

Well, this is a nice story, but I am afraid it is out of date. At some point last year, GNU Hurd became relevant again, which long-time contributor Samuel Thibault explained to a packed room at the FOSDEM conference earlier this year. A port of the Rust compiler greatly increased the amount of application software available. A 64-bit port of GNU Mach and GNU MIG (the Mach Interface Generator, the interface description language that describes the data structures Mach processes use for IPC) is complete, so the OS can take advantage of modern processors and large amounts of system memory. When I say “modern processors”, x86_64 support is mostly ready, and AArch64 (64-bit ARM) is experimental.

By running a “rump” NetBSD kernel in user-space, Mach gets modern networking, USB, and other drivers so that it can actually run on computers that contain those modern processors. Long-dormant multiprocessor code (CMU Mach was originally designed for supercomputers, which were envisioned at the time as symmetric multiprocessing systems) has been rewritten, so that GNU Mach is now multicore, albeit with most Hurd processes still residing on a single core while the team audits their parallelism safety. Journaling filesystems are nearly ready.

So complete is GNU Mach and GNU Hurd, that the GNU Guix system offers it as an alternative kernel choice in the installer, if you do not want to use the Linux-libre default kernel. There has been a Debian GNU/Hurd distribution for donkey’s years. It may have been April Fool’s when Gentoo announced that they were switching to the Hurd, but the availability of scripts and a virtual machine image with running Gentoo/Hurd was no joke. Your author is running it now, with this repository checked out in git and the GNU emacs editor making some final corrections to this article.

Today, GNU is fully usable, it is just not big and professional like GNU plus Linux. Some of the ideas that had to be bolted on to Linux to make it “big and professional” are native parts of the design when you use GNU Mach and the Hurd. Making isolated environments like the podman containers we use to create and publish “De Programmatica Ipsum” requires an unholy amalgam of cgroups, namespaces, and other features that Linux has sprouted over time. In a Hurd system, you just define and launch a subhurd: an independent set of the UNIX-replacing daemons that has limited access to the host HURD’s capabilities. GNU Guix also offers the intriguing possibility of the “childhurd”—a Hurd environment you define and run in your Linux-based Guix environment.

If your idea of the Hurd is that it was a nice idea once upon a time that never came to anything, I would recommend revisiting it now. You will be pleasantly surprised.

Cover photo by Helena Pfisterer on Unsplash.

Similar to those days of yore, “dramatic” is quite an appropriate word to describe the times we are living in; we are very far away from “the end of history” thesis proposed by Francis Fukuyama between 1989 and 1992. In our nerd minds, the sense of dread is accelerated by the fact that no dystopian sci-fi author ever came up with a scenario like the one we are doomscrolling on our devices every morning. The future used to look like flying cars and teleportation to Mars; instead, we had a fascist comeback streamed live over TikTok.

It is in such historical context that, while we were busy preparing this very text, the French government announced plans to migrate an as-of-yet unknown number of computer desktops from Windows to Linux. Big tech, an admittedly US-based contraption, has turned against old allies and made Google’s old “don’t be evil” mantra a forgotten memory from a bygone era.

Linux becomes, as a matter of fact, the “non-aligned” option of operating systems, in stark opposition to the cold war represented by the duopoly of Windows and (admittedly, to a lesser extent) macOS. (We have already talked about the mobile duopoly in a previous article, a market in which Linux is present in a different yet very strong way.)

The French decision, albeit late, is wise, commendable, and reasonable. If there is one thing we should learn for the current times, is that we cannot trust anymore in the desires and values of a psychotic government. And this includes operating systems, software, SaaS offerings, or whatever comes from the other side of the Atlantic.

(As a Swiss citizen, I would love to see my government follow the same path as France in this respect, but Switzerland has a track record of siding with the wrong side of history in order to maintain their beloved neutrality, so I am not holding my breath at this point.)

The problem is that, as far as options go, Linux is a terrible third one.

Do not get me wrong; I am a very happy Fedora Linux user, and I am using it at this very moment to write the lines you are reading. But I work in IT, and I am willing to put up with the myriad shenanigans Linux brings upon users. The work that French IT administrators is about to start is pharaonic, and I am not mincing my words.

Why do I say that Linux is a terrible option? Because of overchoice, and because we are all very tired indeed.

Overchoice is a psychological factor with quite a history. First explained by Alvin Toffler in his 1970 book “Future Shock”, and then popularized as “The Paradox of Choice” by the 2004 book of the same name, it is an intuitive part of our current world.

Here is a fun observation; one of the biggest criticisms that communism has received across the ages is that of lack of choice. Common was the mockery between the spartan looks of a Soviet grocery store, offering a very limited set of products (if any), with the overabundance of American supermarkets, created thanks to the forces of the “free market” that should never be stopped.

Yet, in the computing world, one of the most striking byproducts of capitalism, we have at most two versions of Windows (“Pro” and “Home”) and just one of macOS (remember when there was a “Server” version thereof?)

Readers well-versed in the history of Apple will surely remember Steve Jobs’ matrix of products when he returned to save the company from bankruptcy in 1997, drastically reducing the amount of products offered by the company to just four: two laptops and two desktops, one of each for “home” and “pro” users. Somehow, solving the paradox of choice was exactly what Apple needed to become the most valuable company on Earth merely 20 years later.

On the non-aligned side of things, and against all market logic, the Linux galaxy, itself, is a realm with a myriad choices. Maybe too much?

First of all, let us bring some terminology first. Nobody installs just “Linux” per se. What users install on their laptops are “Linux distributions”, also known as “distros” in the jargon and slang of this fringe realm. Longtime Linux expert Michael Kerrisk explains distributions much better that I could:

Precisely speaking, the term Linux refers just to the kernel developed by Linus Torvalds and others. However, the term Linux is commonly used to mean the kernel, plus a wide range of other software (tools and libraries) that together make a complete operating system. In the very early days of Linux, the user was required to assemble all of this software, create a file system, and correctly place and configure all of the software on that file system. This demanded considerable time and expertise. As a result, a market opened for Linux distributors, who created packages (distributions) to automate most of the installation process, creating a file system and installing the kernel and other required software.

The earliest distributions appeared in 1992, and included MCC Interim Linux (Manchester Computing Centre, UK), TAMU (Texas A&M University), and SLS (SoftLanding Linux System). The oldest surviving commercial distribution, Slackware, appeared in 1993. The noncommercial Debian distribution appeared at around the same time, and SUSE and Red Hat soon followed. The currently very popular Ubuntu distribution first appeared in 2004. Nowadays, many distribution companies also employ programmers who actively contribute to existing free software projects or initiate new projects.

So a “Linux distribution” is just a wonderful thing composed of a myriad different software thingies, forming what most users would end up calling an “operating system”. And just how many different thingies could be distributed this way? Hang on tight little tomato, this is going to be quite a ride.

• Some distributions are “free as in beer and free as in freedom”, in which case support means talking to fanatic users on a Discord forum telling each other to RTFM. On the other hand, some other distros actually cost money, in exchange for actual support, maybe even a 0-800 phone number to call when in despair, better compatibility with a variety of hardware, or some other warm feeling for you to feel inside. This latter case is usually preferred by businesses, for reasons that should be obvious by now.
• Some distributions are explicitly designed for beginners, others for more advanced users (the definition of which is always vague), or for specific use cases like conducting business, playing games, writing software, und so weiter.
• Some distros have specific hardware targets: some work fine on a standard laptop, while others work better on dedicated workstations, or maybe on servers, or even supercomputers, mainframes, or some embedded system NASA ships inside a probe to Mars.
• Some are easier to install that others: some might include a graphical “wizard” interface, while others… well, I hope you enjoy typing on your keyboard.
• Some are already localized for specific countries, which is something some users might prefer (or be forced to use). Most notably come to mind the ones from North Korea, China, Sweden, Turkey, Lithuania, Romania, Greece, Philippines, Colombia, New Zealand, Italy, Brazil, and of course Argentina.
• Then there are the CPU architectures supported, for an outstanding variety of computers out there… even though if most humans are running on some “86”-compatible thing. Of such variety, each distribution picks their own preferred targets, changing their mind as years go by.

And then come the esoteric parameters that make or destroy distributions:

• The Kernel (the what?): the official from kernel.org, or the one from Linux-libre, Illumos, GNU Hurd, Haiku…
• Rolling release or not?
• Able to run Windows and/or Mac apps, or not?
• “Non-free” packages and drivers, available or not?
• File system: ZFS, FAT, ext, Btrfs, XFS…?
• Init system: runit, systemd, sysvinit, OpenRC…?
• Window system & protocol: X or Wayland? (Whatever those things are, they will restrict your ability to run some of your preferred software. You have been warned.)
• Package manager: APT, RPM, apk, pacman, pacstall, Homebrew, flatpak, snap…
• C standard library: glibc, musl, µClibc, µClibc-ng, klibc, Newlib, EGLIBC, diet libc, Bionic…
• Desktop environment (inhale deeply): GNOME, KDE, LXDE, Xfce, CDE, herbstluftwm, i3, bspwm, Enlightenment, Sway, Cinnamon, Fluxbox, MATE, JWM, Qtile, Openbox, Blackbox, Claude’s Tab Window Manager, EMWM, NsCDE, FVWM, COSMIC, olwm, OpenWindows, Java Desktop System, NeWS…

(Takes a deep breath, shakes his head, keeps writing.)

Imagine going to a McDonald’s (another pillar of our capitalist world) and similarly being asked a myriad of questions before ordering a Happy Meal. You would run away in despair; yet, this is the reality of the Linux galaxy, where for better or worse, choice is king.

So much for communism, am I right Steve?

The reality is that most users in 2026 compute very happily with a relatively recent 64-bit Intel-based laptop, with 8 or 16 GB of RAM and a 512 GB hard disk, probably formatted with Btrfs, bundled with the GNOME or KDE desktop environment on Wayland, using systemd, consuming software from either the APT or RPM package managers, including Flatpak for a more end-user-friendly interface to install userland applications, and with LibreOffice and Firefox pre-installed, thank you so much. And that means in general Ubuntu (or any of its variants, like Zorin OS) or Fedora (for slightly more advanced users).

If you are into building containers, we cannot recommend Alpine too much.

And if you are a really, really, really advanced user, particularly of the paranoid kind, some mix of Arch or Qubes OS will do just fine. We have mentioned the latter in a previous article about Joanna Rutkowska:

She is also the founder and main developer behind Qubes OS, described as a “reasonably secure operating system”, and praised by none less than Edward Snowden himself.

Finally, for the French government officials reading these lines in quest of enlightenment, you might want to consider using SUSE, RHEL, or even some business-friendly versions of Ubuntu. (Disclaimer: I am currently working for the company that makes RHEL and Fedora.)

There you go, I have just solved your Linux overchoice in a couple of paragraphs. You are welcome. If all else fails, you can even test individual distros directly from the comfort of your browser, no need to install anything on your laptop.

Cover photo by 愚木混株 Yumu on Unsplash.

Hannu Puttonen followed his gut instincts, and directed “Mr. Bragg Goes to Moscow” (1988), his first documentary, in which followed British songwriter and left-wing activist Billy Bragg on a concert tour of the Soviet Union during the Perestroika era. Because of course, why not. In the same vein, came later “Bring the Beat Back!” (1992), one of the earliest documentaries to pay attention to the burgeoning techno scene, featuring pioneers like Bill Drummond (from The KLF) and Richard H. Kirk (from Cabaret Voltaire). This documentary was released well before Prodigy, Daft Punk, or Moby made electronica mainstream. Or last but definitely not least, “Momus Man of Letters” (1994), an experimental documentary about the eccentric Scottish musician Nicholas Currie, aka Momus, featuring appearances by Jarvis Cocker of British britpop legend Pulp.

Still reading? If any of the names in the previous paragraph rang any bell in you without having to click to read their Wikipedia entries, it means that you are, just like the author of this article, a proud member of Generation X.

Hannu Puttonen was, then, the perfect filmmaker for the first documentary about Linux, and as explained above, not only because he was Finnish like Linus Torvalds himself. So came to be “The Code” (2001), a very fittingly hour-long documentary that we have decided to feature as this months’ Vidéothèque entry.

By the time Puttonen interviewed Linus, the Kernel (in uppercase, please) was barely a decade old, and yet it was gently starting to stir the pot of technology economics. For the sake of narration, the early story of the Kernel is then split in three major sections: birth, philosophy, and economics.

First and foremost, Linux was born a true hobby project. We all know that by now. But back in 1991, having an operating system developed via the collaboration of developers (or “worker ants”) spread all over the world was unprecedented, radically subversive, and fascinating. Of course, the documentary explains around minute seven that “Linux” the kernel is not the same as “Linux” the operating system.

Then comes the philosophy. As I wrote in a previous article of this magazine,

Everything changed in 1998. That is when Christine Peterson coined the phrase “Open Source,” deliberately masking the business-unfriendly moniker of “Free Software” which Wall Street abhored so much. More or less at the same time, Netscape decided to rewrite its own product. Such wise decision, widely celebrated by the “community” helped Microsoft win the infamous browser wars; this situation ultimately begat Internet Explorer 6 and its horrible crush on web development for the next decade.

Richard Stallman has spent countless hours for the past 30 years explaining people that Free Software ≠ Open Source, but few people are paying attention. This, also, is explained in the documentary.

Microsoft took notice and decided to attack the whole concept. Hence the final part of “The Code”, telling us about the economics and dynamics of the Linux Kernel project. From Torvalds’ “Benevolent Dictator” status, to the “dot com boom” of the late 1990s, and even showing an interview of Bob Young, one of the founders of Red Hat around minute 38. It all ends with a nice bow, predicting the impact of Linux in emerging markets and its impact in software intellectual property, a never ending issue, around minute 48.

Oh, and our preferred quote, from legendary Kernel maintainer Alan Cox around minute 24:

To me code has more in common with for example poetry or some kinds of writing. The beauty of it is in the structure, in putting ideas across one at a time in a clear way. So a good piece of code you read without comments and it’s immediately obvious why it’s been written, how it’s elegant. So you’re looking for code which is both clean and elegant. But also doesn’t rely on clever programming tricks, doesn’t make assumptions which may not be true in the future. Because the last thing we want to do is having much code in the Linux kernel which requires large amounts of effort to keep it working. We want code which will just continue to work, and work forever.

This film having been released in 2001, no mentions can should be found therein about “The Cloud”, Android, containers, Kubernetes, NASA’s Ingenuity, Valve’s Steam Deck, cars, or other interesting things people have built upon Linux during the first quarter of the 21st century. On the other hand, TiVo was around at the time of the release of this film, it was already using Linux, and not without controversy.

Internet wisdom usually advocates for not reading comments, but I feel the need to reproduce one from YouTube user Peter Trinh, which faithfully conveyed the spirit of the documentary, resonating ideas around a “decentralized economic systems based on mutual aid and voluntary cooperation” we talked about in a previous article:

I just saw this documentary. I really enjoyed it. I loved the passion and beliefs of people that showed through. This is the kind of stuff that enamored me to computers and Linux in the first place. A sort of innocence, curiousity, and a deep desire to do something good, and doing the work for a vague something-something that is larger than us. So much that we would be willing to do this lovingly as a hobby. I really miss the days like this when we could share this together, even across distances and mindsets.

There is nothing preventing us from bringing those days and those feelings back into fashion, other than our own will, that is.

Watch this month’s Vidéothèque entry, “The Code” (2001), by Hannu Puttonen, on YouTube.

(Oh, and if you are fluent in Finnish and cannot get enough computer history in your system, we can recommend watching the launch of Linux 1.0 on March 30th, 1994, by Linus Torvalds himself. You are most welcome.)

Cover snapshot chosen by the author.