In this edition:

• Graham explains the wonders of a programming language that has been able to adapt in an ever-changing world.
• Adrian enumerates many of the wrong reasons why FORTRAN/Fortran is not at the forefront of computing today.
• In our Vidéothèque section, we watch “The Beginnings of FORTRAN”, a documentary featuring John Backus himself.
• In the Library section, we review “Teach Yourself Computer Programming in FORTRAN” by Arthur S. Radford and “A FORTRAN Coloring Book” by Dr. Roger Emanuel Kaufman.

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 Sam McNamara on Unsplash.

He correctly identified an industry trend, but this is more due to leaky abstractions and poor design choices than any law of nature (in fact we have laws for evolving software systems, courtesy of Manny Lehman, and most of these laws were available to Steve). With sufficient investment, you can keep adapting your platform to the future, without disrupting your lucrative past.

So while the technologically-advanced Amiga ran out of steam when the custom chipset that leapt it ahead of its competitors in 1985 held it back in 1990, other vendors kept their platforms relevant through reinvention and sheer bloodyminded effort. It was only in November 2011 that Oracle Solaris 11 dropped compatibility for programs designed to run on Sun Microsystem’s Solaris 1 (a.k.a. SunOS 4.1), which was released in 1991 and supported through 2003; Solaris 1 was a BSD UNIX and all subsequent versions were based on AT&T’s System V Release 4. Windows does a great job at compatibility with existing software, even after replatforming the PC version of the OS from MS-DOS to Windows NT. The Macintosh platform goes through bursts of emulating old variants while establishing new ones: PowerPC Macs ran m68k software; Mac OS X (briefly) ran “Classic” software; Intel Macs (briefly) ran PowerPC software; you are probably reading this at the tail end of ARM Macs (briefly) running Intel software.

Through all this churn, uncertainty for customers, and change in direction, some platforms have quietly plugged away, continuing to work just as well in the 2020s as they did in the 1950s. Literally. We are talking about the three living fossils of programming, perfectly adapted to their niches and thriving while other species come and go around them: 1958’s LISP (which we covered in our Functional Programming issue); 1959’s COBOL; and the oldest of them all, 1957’s Fortran.

Yes, Fortran from that era is set in small caps, and we even use a nice font (Garamond) that shows the small-caps variant correctly. Developed as the “IBM Mathematical Formula Translating System”, the goal of Fortran was to produce a high-level language that made it easy to enter mathematical equations, and produce efficient compiled code that would be acceptable to programmers used to hand-carving assembler statements.

And boy, did people enter mathematical equations! If, at any point in the last few decades, you have taken a flight, or driven a car, or filled a car’s fuel tank with petrol/gasoline or diesel, watched or read a weather forecast, taken medicine, bought something that is made of a modern material, or otherwise made use of the latest advances in science and engineering, you are a part of the great Fortran ecosystem (we can drop the small caps now, as the authors had to given the limited typographic capabilities of the IBM 1401 mainframe machine).

Its longevity is due to its adaptability; FORTRAN 66 introduced library functions, for example, while FORTRAN 77 supported block statements and structured programming. Fortran 90 gave programmers access to lower-case letters (and thus set the name with only the capitalised initial F). Later updates add generic programming, object-oriented programming (even COBOL has this now) and concurrent programming. The irony of the statement from Steve Jobs that opened this article is that while his NeXTSTEP platform indeed came and went, people used NeXT computers to maintain Fortran software that predated the platform’s introduction and that survives today, long after its disappearance.

Your humble author knows this because he is part of the story. One of my earlier jobs, if you skip my newspaper delivery and corner shop assistant phase, was managing a lab of NeXT machines in a physics department. Yes, we installed gfortran, and yes, the astrophysics researchers used them (along with much faster PCs running the upstart Linux platform) to perform image analysis on data in the FITS image format. They did while the atmospheric physics folks were not running their fluid dynamics simulations, anyway. A lot of the code still followed the old FORTRAN layout rules, with line identifiers in the first 5 columns (unless the first column was C to indicate a comment).

Fast forward quite a lot of years, and I found myself helping to build a parallel debugger for high-performance computing (HPC) systems; in other words, thousands of Linux computers all connected together and running the same program at the same time. The answer to the question “how do you expect me to debug this system, run the same gdb command on thousands of computers at the same time?” is “yes, exactly that, thank you”. But you get a nice UI to drive gdb, and to graph the thousands of values you get back from every p command.

Of course, the software we were debugging (or helping others to debug) is overwhelmingly written in Fortran. Sure, some people switched to C++, and it is not pure Fortran, with a combination of non-Euclidean shell scripts and Python drivers setting up the core models, and some of the mathematical heavy lifting might be outsourced to CUDA these days, but so much cutting-edge science depends on Fortran that it is best to think of it as the modern, scientific language that always has been; a demonstration of what a computing ecosystem can be when it adapts with the times.

Cover photo by Julia Koblitz on Unsplash.

The truth is that Fortran (in whatever spelling) was already on the way out when I started my career in IT, merely 9 years after the publication of the BYTE Magazine article mentioned above. Whatever happened, it was already underway in 1997. The times of John Backus creating the language at IBM were a lonely, distant memory.

We could dive into the reasons why Fortran was pushed aside in the toolbox of most software programmers, but instead we are also going to imagine a world in which Fortran not only never faded away but instead remained a major player in the field. Why not? After all, and I recommend you do that, you can always use apt, dnf, or pkg to install one of the latest versions of GNU Fortran 2023 on your workstation, and you will discover a beautifully simple language, terribly fast, very modern, easy to write and read, and that is perfectly capable of doing anything you want (“Turing-complete,” remember?)

Fortran, against all odds, is still there after more than 70 years since the first program written with it ran on September 20th, 1954. In those pre-historic times, when mainframes roamed the Earth, variable names had a maximum limit of six characters, and variables holding integers must have a name starting with I, J, K, L, M, or N. Talk about Hungarian notation.

And it was more than that: it was actually the language of choice for Real Programmers™®©, as stated in a letter to the editor published in the July 1983 issue of “Datamation” magazine:

The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses. Real Programmers use Fortran. Quiche Eaters use Pascal. Nicklaus Wirth, the designer of Pascal, gave a talk once at which he was asked, “How do you pronounce your name?”. He replied, “You can either call me by name, pronouncing it ‘Veert’, or call me by value, ‘Worth’.” One can tell immediately by this comment that Nicklaus Wirth is a Quiche Eater.

(I guess we should be thankful the author added “or she” to their description of Real Programmers.)

How little has the industry changed in 43 years? Le sigh. Where was I? Ah, yes, trends.

The first hype train that Fortran arguably missed was, let us be honest, object-oriented programming. To be taken “seriously” in the 1980s, you needed to support objects, and there was no way to avoid that. And the first Fortran standard that actually did that came in 2003… that is, 8 years after Java had eaten the whole OOP cake.

Imagine if Fortran OOP features had been available in 1990 already. Polymorphism, inheritance, encapsulation, and so many other buzzwords that the Gang of Four, the Three Amigos, and many other jazz bands of the era were so happy to repeat ad nauseam at each conference. But Fortran had already been slow at introducing structured programming in the 1970s, so the inertial forces that drove its evolution were already at play decades before.

That is probably the most important reason why Fortran missed the OOP hype train: its committee-design nature, which involved particularly long discussion sessions, sometimes seemingly endless ones, in which little or no progress would be made. Mark Jones Lorenzo, in his 2019 book about the history of Fortran, induces deep sigh after deep sigh in the reader while enumerating the various moments into which the language slipped into oblivion. There were many, and they are all unfortunate.

(Actually, no, scratch that: it was not that the committee was slow; it was also that the industry moved at an incredibly fast pace. To give them some credit, it was not entirely their fault. Driven by marketing and hype, the best was buried by the popular, as is usually the case.)

I would argue that the web was the second big trend that Fortran missed; fast-forward to 2026, where are the server-side frameworks to build REST APIs in pure Fortran? There was one available framework out there, called Fortran.io, but I have to point the user to a snapshot on the Internet Archive (again) from May 2026, because the owners of the domain let it slip away, and now somebody has cybersquatted the domain with some gaming stuff you do not want to see.

The web was my first contact with IT in 1997, and it was a domain where you would use C++ to build browsers, JavaScript to add pizzazz to your web pages, and Java to build backends. Well, and (sadly, may I add) also VBScript, which was the choice for quick-and-dirty database-backed websites (or “3-tier architectures” as we called them back in the day) in a world of Microsoft NT-powered servers crippled with Back Orifice exploits. There was no Fortran in sight. Nothing at all. Nope. Nada.

I let you choose between the possible third (and following) missed trains: in no particular order, we can imagine a world where Bitcoin and other cryptocurrency brokers were created and ran with Fortran. Or another in which developers could create iOS and Android apps with it. Or where developers could run Fortran-based APIs in their Kubernetes cluster (see above). And another where Jupyter Notebooks would run Fortran kernels natively (ok, this last one actually is possible, thanks to the LLVM-based LFortran project), and this would have displaced Python as the default language for AI applications and scientists.

It is all sad indeed. Python (arguably, mostly through NumPy and SciPy) ate Fortran’s lunch and ruthlessly pushed the old man aside, with bad manners and leaving the scientific and engineering communities to deal with a (let us be honest here) slower language (oh, but it is interpreted, not compiled. Big deal.) Did Fortran deserve better? Yes, of course it did. Was the Fortran committee up to the task? Hardly.

Not all is lost, however. The LLVM Fortran compiler has been officially available since last year. Intel is still distributing and documenting its Fortran compiler… and there are more compilers available if all else fails. NASA is still heavily using it. It is still very much used in high-performance computing (HPC) applications. Compilers compatible with the 2023 standard can compile FORTRAN 77 programs without problem. And for whatever it is worth, Fortran made it to the 10th position of the TIOBE Index in May 2024 (at the time of this writing, it is still featured in a very honorable 19th position.)

Fortran is still compiling and still running, and this is for the foreseeable future. The community around the language is still strong, vocal, and active, seemingly “resurrecting” the language and keeping its legacy alive, hopefully with stronger will and more agility than the previous generations.

A 2022 paper titled “The State of Fortran” (freely downloadable from arXiv) summarizes the situation in much better words than this article ever could, but suffice to quote the following:

Fortran is perceived in some software development circles as archaic, lacking the features and conveniences of newer languages, and characterized by an obtuse syntax. However, such considerations typically stem from a lack of familiarity with Fortran standards later than Fortran 77.

Say it again louder for the ones in the back. Also, I do not know who needs to hear this, but just in case: in Fortran 2023 you can have variable names longer than six characters, and integer ones do not need to start with I, J, K, L, M, or N.

For a language still supporting the GOTO keyword, Fortran was much luckier than BASIC ever was.

Cover photo by NASA Hubble Space Telescope on Unsplash.

This month’s Vidéothèque entry is “The Beginnings of FORTRAN”, a short low-resolution window to a long-gone time, 70 years in the past, when a guy named John Backus decided that writing machine code by hand was a tedious and inefficient.

In this video we are introduced, one by one, to the members of the original FORTRAN team and learn quite a few crunchy details about what it meant to create a programming language when there were not any to take inspiration from. For example, one of the project motivations was that the IBM 701 (one of the direct ancestors of the 1401) was simply too fast (kids: Tokenmaxxing was not a thing yet). The problem was, they could not figure out how to write code by hand fast enough to keep the machine busy; you see, “machine time” was insanely expensive back then, so you had better be running some useful program to justify the cost.

Thus, they were forced to invent a higher-level language just to keep hardware busy. Following that reasoning, I guess they could have invented video games instead, but hey, let us be honest, that would not have passed the business filters at IBM.

The uncertainty was such that whenever management asked when FORTRAN would be ready for sale, John Backus simply replied, “Come back in six months.” They kept this charade up for three straight years: take notes for your next sprint planning session (inversely, if you are a manager, beware if you hear this very sentence in said meeting).

Thankfully, Lois Haibt, who was originally hired as a “technical typist,” ended up becoming one of the brightest technical engineers in that original FORTRAN team. Take that, rigid HR job descriptions and male-only environments. As she nonchalantly mentions at 05:51,

Nothing was known about parsing. It was all invented at the time.

The team worked in such a secretive, unstructured, and intense manner that the IBM elevator operator referred to them as “the white coats,” treating them as irregular mad scientists within the otherwise buttoned-up suit-and-tie IBM corporate culture of the 1950s. And naming was already one of the most complicated things in computer science: John Backus would constantly pitch terrible names for the language. When he finally proposed “Formula Translation” (spoiler alert: “FORTRAN”), the consensus from the team was a collective groan (“I went ugh”, recalled Haibt). But they had nothing better, so it stuck. As Harlan Herrick mockingly says in 07:51:

“FOR-TRAN”. It sounds like something spelled backwards.

The punchline? The compiler this ragtag group of “white coats” built without any theoretical foundation was so terrifyingly optimal that it produced the fastest, most efficient machine code available for the next twenty years. For the following two decades, or roughly until Pascal and C and C++ (and a decade later, Java and Python) took over the professional coding markets, FORTRAN reigned as the most pragmatic approach to building software on any computer available at the time.

This video reminds me of Jim Henson’s 1967 “The Paperwork Explosion” short movie, which we reviewed earlier in this magazine, and which is also directly related to something coming from IBM. Here go some more videos for your further exploration of FORTRAN/Fortran: “FORTRAN in 100 Seconds” by Fireship and “The Untold Story of FORTRAN” on the CodeSource channel. Or jump directly to what Bret Victor had to say about it in our first Vidéothèque entry ever.

Fortran is not fashionable these days anymore, sadly. It will most probably not win you any points at your next retrospective meeting. But it is alive, it is ruthlessly fast, and as this video reminds us, it was forged by those who had to invent the wheel before they could build the car.

Watch this month’s Vidéothèque movie, “The Beginnings of FORTRAN”, on YouTube.

Cover snapshot chosen by the author.

None of that comes close to the state of decay of my copy of Arthur S. Radford’s “Teach Yourself Computer Programming in FORTRAN”. As you can (not) see from the cover image, this is no longer a book so much as it is a collection of numbered sheets of paper loosely filed in a wraparound card sleeve. This is a book that has been opened and closed so much, both by myself and by its previous owner (a ballpoint inscription on the inside “cover” tells us this was a pharmacist from Bath, England), that the pages have completely separated from one another.

I think we should lay the blame as much at the feet of cheap binding as overuse, but both are present. A Teach Yourself book is designed to be read once, if at all: mostly bought by well-intentioned people who treat instructional books first as an osmotic source of information (if it is on my shelf, I will acquire the knowledge therein somehow), and then a source of embarrassment (I always meant to learn FORTRAN, but I never found the time). I find myself coming back to this book every time I need a refresher on how basic FORTRAN syntax works, which is infrequently enough that I cannot remember it, but often enough that I can readily put my hand to this book, pick it up off the shelf, then spend ten minutes trying to shuffle the pages back into the correct order.

The thing is—and this is a lesson that the rest of the computing industry would do well to recognise and to heed—everything in this book still works. FORTRAN might have evolved over the intervening decades, but never to the point where it forgot to fight for the user. Download gfortran in your favoured way, type any listing from this book into a file that you save with a .f extension, compile it, and you will find that it works in exactly the way that it did back when the book was written in 1975. Your fancy new compiler does not need program statements to start in column 6, but if that is how you write your code, that is what will work. Indeed when I typed in one of the programs just now, I got but one warning: in Fortran 2018, DO <LABEL>...<LABELED STATEMENT> was formally deleted in favour of the DO...END DO construct, introduced in MIL_STD_1753 and standardised as part of Fortran 90. Never fear, dear reader, my code still compiled and worked, it just had a warning.

And do not get confused into thinking this is a book for teaching FORTRAN programming. It is a book that teaches “Computer Programming in FORTRAN”, so you also learn how to decompose problems into sub-problems, how to model program logic with flowcharts, and how to distinguish text files encoded with EBCDIC from those encoded with ASCII. The author opens his preface with “There can be no doubt about it, the computer is here to stay.” He is correct, and 51 years on from that writing, the computers that stayed around are just as capable at running Arthur Radford’s FORTRAN code as the computers he used when he wrote the book.

Cover photo taken from the Internet Archive.

We are talking about “A FORTRAN Coloring Book” by Dr. Roger Emanuel Kaufman, originally published in paper format by the MIT Press in 1978. This is the book that showed the non-standard, non-conformist path that many other great authors have followed. As we said in our article about _why last February:

Remember our article about programming artists? We have continued to honor those outcasts as often as possible: the aforementioned Kathy Sierra, Douglas Hofstadter, Geoffrey James, Andy Clarke, Jens Müller & Julius Wiedemann, Alex Wiltshire & John Short, Pastor Manul Laphroaig, Vikram Chandra, and even our beloved Dr. Dobb’s Journal of Computer Calisthenics & Orthodontia, one of the inspirations for the magazine you are reading right now.

I feel we should add to this illustrious list the “Oh! Pascal!” book series by Doug Cooper, published between the late 1980s and early 1990s, one of which showed the way to become a programmer to this author, more than 30 years ago. And of course, “The Cartoon Guide to the Computer” by Larry Gonick, who practically built his career on the stylistic foundation Kaufman laid. If you look at the index lettering in Gonick’s early books, the inspiration is a dead giveaway.

Oh, and before I forget, here is another one that comes to mind in the same style, which we talked about in our issue about the BASIC programming language three years ago:

The first is the memorable “10 PRINT CHR$(205.5+RND(1)); : GOTO 10” (2012) by Nick Montfort, Patsy Baudoin, John Bell, Ian Bogost, Jeremy Douglass, Mark C. Marino, Michael Mateas, Casey Reas, Mark Sample, and Noah Vawter, a book dedicated to a single line of Commodore 64 BASIC code; a title so unique that it deserves an entry in this Library section of its own.

Until we find even earlier examples of this style, I will quite safely argue that Dr. Kaufman was the first to approach the subject of programming with hand-drawn cartoons, lightheartedness, and joy. Why should all programming books start with a “Hello, World?” Why are there not any Rust coloring books available these days? (Ah, well, reading has also become a lost art, apparently.)

Dr. Kaufman’s résumé provides quite a few hints to the level of Renaissance Man he is. Professor Emeritus of Engineering and of Anatomy and Cell Biology at George Washington University, trained as an engineer and as an actor (I am not kidding, scroll down his home page and take a look at that MFA from Yale University), with a long list of published papers and research endeavors, and even some patents under his name, Dr. Kaufman wrote the definitive guide that shows us, 50 years later, how FORTRAN (still all in uppercase) used to be, merely 25 years after its creation.

(I wonder if Dr. Kaufman was in any way related to Andy Kaufman, another brilliant example of counterintuitive talent taken to the maximum. I can see parallels between them both. But I digress, as usual.)

As expected (or not), “A FORTRAN Coloring Book” is entirely handwritten and illustrated; a refreshing slap in the face for those of us who obsess over perfectly rendering our Markdown through intricate Pandoc, Typst, or LaTeX pipelines. There is no automated typesetting here. It is chaotic, brilliant, and deeply informative. I wish there were more books like this.

Some trivia from this gem? The rhyming and whimsical illustrations in this book were so effective that the American Mathematical Monthly reviewed it in November 1978 with a four-line poem. Even better, Ted Geisel (the one and only Dr. Seuss of Grinch fame) sent Kaufman a letter complimenting the book and wishing he would have had a text like that when he was a student at Dartmouth. The two authors traded autographed copies of their respective books.

Another juicy one: the book was on sale globally, from the MIT Museum Shop to the Smithsonian. However, a bootleg German publisher took the piracy game to a sickening new level: they not only plagiarized the book, but they actually translated the code examples from FORTRAN into Pascal. What do they say the highest form of flattery is? Well, there you go.

In this age and time when the art of programming is being sucked into LLMs and where juniors are left behind in their way to proficiency, let us remember the work of an author who truly believed there was a different way to teach them how to code.

Bonus: if you are interested in the complete history of FORTRAN/Fortran, I can only recommend you grab a copy of Mark Jones Lorenzo’s 2019 excellent opus “Abstracting Away the Machine: The History of the Fortran Programming Language”. Yes, regular readers of De Programmatica Ipsum will find the name familiar, and they should trust their instincts: we reviewed his book on BASIC three years ago. I actually debated for a while if I was going to write a review for this one, but I decided to leave that to others.

Dr. Kaufman’s book is freely available today in DRM-free PDF format, for your enjoyment, directly from the author’s home page. You can even find used copies on various online bookstores, so please do yourself a favor and get one of those. I know what I am talking about; I just ordered mine.

Cover art chosen by the author from the book.

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.