In this edition:

• Graham argues that the “Killer App” phenomenon is in danger of extinction.
• Adrian enumerates some examples of “App Killers”.
• In our Vidéothèque section, we watch the moment Dan Bricklin told his team about the release of the first IBM PC in 1981.
• In the Library section, we review “Using ARexx on the Amiga” by Chris Zamara & Nick Sullivan.

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 Joshua Coleman on Unsplash.

Really the only killer app I was in on the ground floor for was the most famously fumbled (though still incredibly successful) killer app in history: Facebook. I was working at Oxford University when Facebook came out, so once they expanded out to campuses beyond Harvard, I was in one of the earlier networks to join up. (You might not remember this from the early days of Facebook, but the site was segregated into separate instances that ran on different “networks”. A member from Harvard would see their Harvard friends, but nobody from MIT.) It turned out that Facebook was the killer app for university computer rooms, and before too long over a quarter of all email handled by the university’s central mail service was Facebook notifications, reminding people like me that that one Philosophy student I met in the pub once and decided to add to Facebook had poked me.

Where is the fumble? Well it turns out that Facebook was the killer app for mobile computing, and everybody noticed it except Facebook. It turns out that when you are super-rich, that kind of mistake is not existential—think Microsoft missing out on the early years of the public Internet, or Metallica opting out of music streaming—it is just embarrassing, and costs you quite a lot of that vast pile of money to catch up. In the early days of Facebook, it was conceived as a live status blog, in the style of the old “finger” protocol on UNIX. The placeholder text for my “wall” (the place in my profile for public posts) prompted “Graham is…”, and I would describe what I am doing in a way that made people believe that I had an interesting life, and was not the kind of person who sat in the computer room writing status updates on the web.

Mobile computing—once the ridiculously poor performance of GPRS was a thing of the past, the abysmal capabilities of WAP were transcended, and service providers stopped charging ridiculous figures for a few kilobytes of HTML—offered a new reality, one in which one could explain what “Graham is…” doing while Graham is doing it. Twttr/Twitter noticed this in 2006. Burbn/Instagram noticed in 2010. Meanwhile, in 2010, only 150 million of Facebook’s 500 million users accessed the site via mobile. Why? Facebook had been in at the start with the Facebook mobile app for iPhoneOS/iOS, frequently the number one downloaded app. But it was not a focus; one person (Joe Hewitt) created the app and in true Facebook fashion, really open source a whole app framework (Three20) that supported development of that single app. When Hewitt left the company in 2009, they needed to take a very different approach. Eventually they just bought Instagram and pretended they were cool all along.

A killer app sits in a precarious situation. It is an app that is so popular, it changes the value proposition of the platform it runs on; people went out and bought Apple ][ computers just so they could run VisiCalc. Musicians bought Acorn Archimedes so that they could run Sibelius. That is a problem for everybody involved. It is a problem for the makers of the killer app, because their platform vendor is not shifting enough kit for them to sell their software to all their customers. It is a problem for the platform vendor, because now they are not in control of the marketing for their product. The people who make the killer app want to port to different platforms, to satisfy latent demand. That is why you can get Sibelius for PC these days, and why Deluxe Paint was available for MS-DOS, Apple ][GS, and Atari ST. The people who make the platform want to diversify beyond the app’s customers, to regain control of the platform. That is why the marketing for the Mac is not all about how it is the latest thing from the people who gave you the opportunity to run VisiCalc. The people who make other apps want to make clones of the killer app, because it shows where the demand is. That is why you have used Excel, and you have not used VisiCalc. And the people who make other platforms want someone to make a clone of the killer app, so that customers choose their platform over the one with the killer app. That is the reason that IBM PC-compatible computers were briefly better marketed as “Lotus 1-2-3 compatible”; it showed that you could run the not-VisiCalc on the not-Apple ][.

The value proposition for software is entirely different in the 2020s than it was in the 20th century. Where Sibelius used to cost £795 to run on the £799 Acorn Archimedes, now you use the free software product MuseScore and do not (have to) pay anything; or you pay under half the previous, one-off price for a lifetime subscription to all future Sibelius releases (same number of currency units, but three decades of inflation later). Other than some die hards who believe in an innate superiority of native applications or of their favoured platform, you will not find much software that is not available for every popular desktop and mobile platform, either via the web or via web-like portable runtimes. No new killer app is going to arrive for any of these platforms, or for an upstart in those fields.

Why did the financial landscape change? Because the platform vendors could not afford to let a killer app take control of their marketing and sales pipelines. App stores exist so that the platform vendors get to choose what software gets sold, what price points and business models are available, and how the software gets described and marketed. No longer does a businessman walk into a computer store and ask for VisiCalc along with whatever box they need to make VisiCalc work; now they have to choose their general-purpose computer and then visit its souk to work out what they are allowed to do with it. Further, the platform vendors get to see what is doing well, and tailor their marketing appropriately—or build their own competing implementation.

Even if an app could break out of that restriction and build an identity that outshines its host platform, there is just no “moat” that defends any one platform from all of its competitors providing the same facilities. It used to be the case that switching computers was a huge deal: none of the software was compatible, none of the file formats were interchangeable, probably a floppy disk you formatted on one type of computer would not even get recognised on a different machine, even if it physically fit in the drive. That was not just true between manufacturers, but from different computers produced by the same company, too: try to run your Commodore VIC-20 software on a Commodore 64, Plus/4, CBM-II, or Amiga 1000. That is no longer true. All platforms have a web browser, meaning the unholy triumvirate of HTML5, CSS3, and JS is the ultimate portable runtime. A software company no longer has to choose a platform vendor and hope they can keep up with demand; they can reach everyone, whatever they run.

Might we get a killer app from the free software world? it is unlikely. When That is happened before, it is been in the narrow (but previously very lucrative) world of software for IT professionals: think GCC, LAMP stack, or Docker, it is pulled the rug out from under the proprietary alternatives, and the pricing floor with it, but has not led to people specifically buying into platforms because That is how you get to run GCC, LAMP stack, or Docker. Indeed it is one of the features of free software that you can modify the software to suit your needs, so if you are on Windows and you want the benefits of all of that free software, you port it. There used to be a whole company, Cygnus (Cygnus: Your GNU Support, now part of Red Hat, an IBM®™© brand), who did just that. Yes, you can buy a computer from System76 or the Raspberry Pi Foundation specifically because it runs Linux, but I am fine with Asahi on my Mac, my neighbour is fine using the Windows Subsystem for Linux, and my housemate just runs Audacity in Windows 11 on their NUC without questioning the value of their kernel. Free software does not have a moat by design, its purpose is to drain other platforms’ moats.

It is more likely that future killer apps will demonstrate the value of a new computing paradigm, and set up one of the platform vendors in that paradigm to be the largest supplier, for the couple of weeks it takes Claude Code to clone equivalent software for their competitors. There are precious few emerging paradigms though. You cannot count the “AI pin”/voice computing paradigm, because you can already do that on things that also have screens, so any compelling voice interaction software is already doable on mobile, desktop, web, and everywhere else. Besides, there are whole generations of humanity who are uncomfortable even having their phone ringer unmuted, who will not walk around talking to a computer like it is Majel Barrett Roddenberry standing behind the camera. Similarly, the whole LLM paradigm changes a lot of games, but not in any way that is exclusive to a single provider; whatever you do with Copilot, anyone else can do with an open weights Qwen model on their own computer (just maybe a little slower). Briefly, MoltBot/OpenClaw looked like being a killer app… but killing what, precisely? People bought Mac Minis, gaming laptops, workstations, they ran with Claude, ChatGPT, Gemini, there is no one “platform” that benefits in the market because of these tools.

Virtual Reality has been just around the corner for about as long as fusion power generation, and as much as it is found meaningful applications in many fields, still has not demonstrated the breakout utility that leads people in the mainstream to buy a headset just so that they can use that one, killer app. Similarly, augmented and mixed reality have even got real electronics that you have actually heard of selling consumer hardware, just not in meaningful quantities. As with VR, nobody has made a killer AR/MR app that makes people buy the hardware to use the software (if you are looking for app ideas, may I suggest a DuoLingo for sign language that tracks your hand movements, or an app for people with prosopagnosia that adds virtual “Hello, my name is” badges to people in contacts?).

Blockchain remains niche (and, for many, confusing: do I need to use a different currency just to run this software?), quantum computing is a mechanism rather than an interaction paradigm, so I think the only other direction from which we might see a killer app any time soon is the one that is furthest from the mainstream: smart dust. I just hope I did not use the phrase “killer app” in a hauntingly incorrect sense, there.

Cover photo by Museums Victoria on Unsplash.

Let us first enumerate some canonical examples of “Killer Apps.” There is a quintessential one everyone (well, at least computer history boffins like the authors of this journal) mentions: VisiCalc for the Apple II. But there are others; unfortunately for VisiCalc, it was not the actual killer app for the IBM 5150 (aka “IBM PC”), because Lotus 1-2-3 took that crown.

In the same category, we can also mention Microsoft Office (and by extension, Excel) for Microsoft Windows, one of those few examples where the same company delivered the platform and the software everybody wanted to run at the same time (which also strongly suggests that spreadsheets did have an oversized influence on shopping decisions back in the day!). In a similar vein, Aldus PageMaker was the killer app for the original Apple Macintosh and the LaserWriter printer, allowing small shops to be able to produce extremely high-quality printouts from their work in a very affordable package (well, at least for businesses).

Other famous examples of “Killer Apps” would be the Unix operating system for the C programming language; in the 1980s everyone wanted to run (or copy or clone or rewrite) Unix, and said passion pushed its associated programming language to unforeseen levels of popularity (still enjoyed to the time of this publication, by the way). More examples in the programming language arena? I could mention Jupyter and NumPy for Python and even the original iPhone for Objective-C.

In the recently published book “Steve Jobs in Exile,” we can read the story of how Jean-Marie Hullot’s Interface Builder was the “Killer App” for the NeXT computer, used by companies in the financial industry and government to build new applications in record times.

There is another interesting example I can relate very directly to. In 2008, an otherwise unknown software developer from Switzerland reverse-engineered the API of the national railway company website. He subsequently released a very early application for the iPhone that allowed users to be able to know when the next train was leaving town. That application was not made with the consent of the SBB-CFF-FFS (that is the name of the Swiss national railway company, with a triple acronym in each of the major national languages of the country). After some legal hurdles and reaching an agreement, said developer sold the source code of the app to the SBB-CFF-FFS, who took over its development. The interesting thing is that the mere existence of this application boosted iPhone sales to incredible levels, making Switzerland the country with the highest concentration of iPhones in the world until around 2011.

Closer to us, one could argue that Argo CD is the “Killer App” for Kubernetes; in the experience of this author, the Argo CD console has become, in various DevOps shops, the default dashboard to monitor and deploy countless applications hundreds of times per day, pushing the “GitOps” paradigm to its pinnacle. I have this small theory of mine that companies install Kubernetes (or their associated products) just for the sake of being able to use Argo CD. And no, I am not kidding, and so far, I have had no facts countering this hypothesis.

But enough of “Killer Apps”; let us talk about “App Killer” now. On many occasions, the software industry witnessed an application obliterating a previous one into oblivion, and the factors that cause this destruction are seldom related to the inherent quality of the incumbent or the competitor.

Occasionally the “App Killer” is just bad business acumen; the Osborne effect, whereby a company drives itself out of business by announcing a better product than the one it is currently selling… before it is available, thereby cannibalizing its demand and cutting short its supply of cash. Ouch. On the other extreme, we have self-cannibalization, something that Apple practiced with gusto during the legendary run of the 2000s; the iPhone, very famously, destroyed the iPod, with both (very profitable) cash flows directed towards the same bank account. Talk about learning a lesson or two from Osborne.

Speaking about the iPhone, we can say that it was the “App Killer” for a few other platforms: Symbian, BlackBerry, and even Adobe Flash. Regarding this last case, it is quite ironic that 15 years later, iPhones (and pretty much any device with a relatively modern web browser) can run Adobe Flash content thanks to WebAssembly and Ruffle.

Another business-related “App Killer” is bad product management. In this respect we can mention Google, which has a long-held tradition of killing products, even relatively successful ones, with short notice and usually without any kind of reasonable upgrade path. There is even a website called “Killed by Google” that keeps track of this (very) long list of casualties. Requiescat in pace, Google Reader. Another interesting case of killing product management skills is that of Facebook obliterating Parse. Mobile app developers old enough to remember this will rejoice. Another recent example? The Humane AI Pin, which effectively obliterated a whole company out of business.

Actually, here comes another fascinating “App Killer,” very en vogue at the time of this publication: Artificial Intelligence, at least the LLM-fueled one, getting massive amounts of Erin Brockovich-fueled backlash from pretty much everyone except tech bros.

Corporate incompetence is another “App Killer” related to the previous examples: we have mentioned Borland in the pages of this magazine, erasing itself out of the minds of developers for apparently no rational reason. Oracle does this regularly too, throwing lawyers at pretty much anyone or anything standing in its way, but with demonstrably higher rates of success than Borland. Oh, and speaking of legal issues, let us not forget that lawyers were the “App Killers” for Napster, too.

Let us not forget about another classical “App Killer” phenomenon: major rewrites. Ah yes, a company decides to rewrite their flagship cash cow, only to discover that it was a gargantuan task, it will never be ready on time, and if delivered, it would be immediately replaced by something better? Comes to mind Lotus 1-2-3 Release 3, Digg v4, AngularJS, KDE 4, Windows Longhorn, Evernote 10, Project Pyramid (an effort to rewrite Microsoft Word in the 1990s, eventually abandoned), the 2024 Sonos app overhaul catastrophe, and the canonical example of them all, the rewrite of Netscape Navigator that would lead to Mozilla Firefox… 6 years later, and conceding the web to Internet Explorer.

All things considered, software remains a brittle thing, not because of the pervasiveness of bugs, but because software markets are extremely sensitive to hiccups of all kinds. The application, actually the whole software stack you are using today, has more chances of disappearing in the next ten years than remaining alive, let alone relevant at all. Those apps and platforms that survive the killing spree, usually deemed “boring” by hype-fueled types, are those that pass the test of time and stability and become actual staples of productivity and mental well-being.

In a certain way, it is a mechanism akin to natural selection, but without anything natural in it.

Cover photo by Maxim Hopman on Unsplash.

In this edition we look back at a staff meeting at Software Arts, held on August 12, 1981, almost precisely 45 years ago. The speaker is Software Arts (not to be mixed with Electronic Arts!) co-founder Dan Bricklin. The full transcript of the staff meeting has been available on Dan Bricklin’s personal homepage for the past 24 years at least, as the Internet Archive dutifully remembers.

The room where the staff met was hot; they complained about the rising temperature right at the beginning, but the heat was nothing compared to the news being delivered. On this precise day, IBM announced its model 5150, the OG Personal Computer. And Software Arts, the creators of VisiCalc, were holding the “Killer App” for the IBM PC… or so they thought.

What makes this (otherwise rather boring) video captivating is not merely the juxtaposition of a scrappy hacker culture colliding with the monolithic, suit-and-tie presence of International Business Machines. It is the knowledge of what happens next.

Bricklin reads a letter from IBM addressed to him and his co-founder, Bob Frankston. The corporate speak is thick. IBM politely but firmly reminds them of their “confidential disclosure” agreements, forbidding them from divulging technical specifications beyond what the Boca Raton IBM Labs have officially sanctioned. The Software Arts team sits in that stuffy room, looking at photocopied press releases and marveling at the marketing brochures, brimming with the pride of having the unquestioned “killer application” bundled with the most important piece of hardware of the decade.

They are celebrating their ascension to the throne. They do not realize they are reading their obituary.

By porting their fundamentally 8-bit application to IBM’s new 16-bit architecture without significantly rewriting it to take advantage of the expanded memory and speed, VisiCalc left the door wide open. Just over a year later, a former VisiCorp product manager named Mitch Kapor would release Lotus 1-2-3. Written directly in x86 assembly to ruthlessly exploit the IBM PC’s hardware, Lotus would make VisiCalc look like a sluggish, archaic toy. VisiCalc’s sales would flatline almost overnight.

But wait a second: did I not just publish an article in this very edition that literally enumerates rewriting as one of the “App Killer” factors? Well, yes, but in some cases app rewritings were required; if not in version 1.0, in version 1.1, particularly when you have such technological transitions as the one witnessed in August 1981. Of course, it is easy to pass judgment in hindsight… 45 years after the facts. Anyway, I digress, as usual. Who knows what history would have been like if VisiCalc had made it to the 1990s? Would our accountants be calculating our taxes with “VisiCalc for Windows 2026” today?

Back to Software Arts. As the meeting unfolds, Bricklin reads off the software lineup for the new machine: a BASIC interpreter from Microsoft, a word-processing app called EasyWriter, and an accounting package from Peachtree. Such was the primordial soup of a new computer back in the day. Neither Doom nor Pascal nor Facebook nor ChatGPT were “Killing Apps” yet in the collective psyche.

The deepest irony arrives precisely at minute 7:06, when Bricklin highlights IBM’s “groundbreaking decision” to open a software publishing department to consider user-generated programs and third-party software. He reads this as an exciting curiosity. In reality, it was the death knell of the closed-silo computing appliance. IBM was building an open platform, and an open platform has no loyalty to its launch titles. The very ecosystem that Software Arts was helping to legitimize was the exact mechanism that would allow their competitors to bypass them entirely.

Pause at minute 10:28 and pay attention to the marketing materials they pass around, featuring a bizarre stock photo of a wife adoringly holding onto her husband as a child plays on the PC, accompanied by pictures of cows meant to represent VisiCalc. They laugh at the marketing department’s clumsy attempts to visualize software. They are dissecting the marketing of a product that they believe guarantees their future, entirely blind to the fact that the IBM PC was merely a vessel for their impending obsolescence.

We often look back at the history of startup culture through the lens of polished retrospectives and survivorship bias. We read about the early days of computing and imagine a clean, inevitable trajectory where the pioneers always reap the rewards of their labor. This video shatters that illusion. It is a beautiful, unvarnished, and quietly tragic look at the exact moment a company reached its absolute zenith. Look at them: they are sitting in a sweltering room in 1981, laughing, smiling, and holding the future in their hands, blissfully unaware of the plans the future was already making to leave them behind.

VisiCalc, their own quintessential “Killer App,” the one that quite rightfully defined a whole generation of computers, was about to be murdered and rendered obsolete in that savage, never-ending ritual of the software industry. I just read again this last phrase, and I cannot believe how corny it sounds, but so be it. I like corny.

Cover snapshot chosen by the author.

For individual customers, this meant a huge upheaval whenever they bought a new computer (which was only once every decade or so at the time), as all of their programs, and all of their data, and most of their peripherals, and half of the BASIC keywords they had learned and all the memory locations to PEEK and POKE, all stopped working with the new system. It also meant huge questions for potential new customers: will software houses still support this computer six months from now? How about peripheral makers? Will my investment pay off?

So then came the era when the vendors made peace with themselves, and they started making compatible model families, which could all (more-or-less) run the same software, and use the same peripherals. They finally learned the lesson of IBM’s System/360, and of course the runaway example of the compatible model family is the IBM PC and its legion of clones. Alongside that, TRS-80 Model III and IV both run TRS-80 Model I software; The ZX Spectrum 128k, +2, and +3 all run ZX Spectrum software; the Macintosh remained compatible with its original model’s software up until Mac OS X 10.5; and all versions of the Amiga could more-or-less run anything designed for the original Amiga 1000.

Now it was safer for customers to buy into a platform, because it looked more likely that they would still be able to get applications (OK, let us be honest, games) and peripherals for the computer a few years out, and that the next time they bought a computer, they might be able to get one that can still use all those games and peripherals. But what would make any one platform more compelling than the others; what gets a customer to hitch their cart to Apple’s horses instead of Commodore’s? By the mid-1990s, all of the platforms that were still on the market had roughly compatible capabilities, with sound being the weird outlier: Apple Computer had settled the suit with Apple Corps and were allowed to play sounds on their computers; PCs were starting to transition from either beeps-only or CD-quality Sound Blasters to CD-quality integrated sound chips; Atari had integrated MIDI capabilities into the ST line all along; Amiga was the laggard, with its 1985 standard-setting Paula chip still the only option in the final CD32 model.

The vendors needed killer apps, but they needed a particular, very constrained, kind of killer app. Something that made their platform more compelling, but that did not crowd out independent software vendors. Something that made everybody else’s software better on their computers, and also made their own software better on their computers.

For a brief period, it looked like this killer app was going to be interoperability, and empowerment. Each platform supplied its own, unique way to interconnect software into a platform-wide automation capability that let the vendor’s customers write scripts, or record macros, that used first-party and third-party software in concert to perform complicated tasks. It was a beautiful time; perhaps the last time that the computer vendors trusted us to know what we wanted and enabled us to go the last mile ourselves.

Windows 95 supplied Windows Script Host, which could communicate with any app on the platform using COM. Apple provided Open Scripting Architecture, which apps could integrate with to make their capabilities available to people who wrote AppleScript. Two other platforms—IBM and Microsoft’s ill-fated OS/2, and Commodore’s ill-fated Amiga—adopted an interpreted language from IBM as the interface to their interoperability features: Rexx.

Amiga Rexx (ARexx) was not actually Commodore’s idea, it was created by William S. Hawes as a third-party product, but Commodore saw the value and incorporated it into AmigaOS 2.0 and every subsequent release, from 1990. Rexx itself is a nice, PL/1-like language with some interesting features: it does not have arrays or dictionaries, but it does have “stem variables”, so the variables named a.1 and a.2 are associated through the stem a, and if another variable i has the value 2, then the value of a.i is whatever you assigned to a.2.

What sets ARexx apart and makes it a candidate for empowerment feature of the (last) century is the idea of the command host. Just like AppleScript’s tell application "Finder" instructs the script interpreter to send a message over to the Finder app, ARexx’s address 'DPaint' tells the interpreter to connect to the port for the DPaint app. The app does whatever the Rexx script requests, and then replies to the message.

What the application receives is a message containing the string was addressed to it, which it can parse using the same format specifiers that CLI tools use in the AmigaDOS shell: the first word is the command name (i.e. the verb) and everything else is a modifier, or parameter. In this way, the syntax is relatively free, but still relatively programming-like, avoiding the trap of feeling like natural language but interpreting input in surprising ways. This problem befell AppleScript, where author Matt Neuberg described it as the “English-likeness” monster.

In this way, ARexx acts as the universal glue that makes Amiga applications part of a powerful suite of interconnected tools, designed, assembled, and controlled by the person using the computer. During this period where a platform vendor’s agent has more access to the apps and content on a computer than its customers do, the suppliers would be well served by remembering a time when they tried to empower their customers, and make sure that the world of computing did not turn out like Nineteen Eighty-Four.

Cover photo by the author.

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.