In this edition:

• Graham makes us realize that you cannot get rid of programmers.
• Adrian is dismayed reviewing the history of Software Factories.
• In our Vidéothèque section, we listen to Damon Edwards tell us the story of how the DevOps movement got started.
• In the Library section, we review “MDA Explained”, “Aspect-Oriented Software Development with Use Cases”, and “Science of Software Product Lines”.

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.

This issue closes the 8th volume of this magazine, also available as DRM-free PDF and EPUB files.

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 Alex Simpson on Unsplash.

To quote from the aforementioned report, conference attendee Jules Schwartz says “Programmers must be controlled, so that they don’t invent beyond the requirements which are assigned to them.” This is such a big problem, that the software engineering memeplex has phrases that describe both its occurrence (“Gold-Plating”) and its avoidance (“You Aren’t Gonna Need It” or “YAGNI”); the latter being a technique that rightfully got labeled “Extreme” on its introduction.

In both theory and in practice, you do not need programmers to write programs. Once you have a description of your system’s capabilities and design, you can automatically generate a program that does what you need. No programmer to create features you do not need; to turn a quick design tweak into a general data-driven layout engine; to rewrite the whole application using a technique they just read about in a Yourdon Press book.

In practice, this approach has drawbacks. Firstly, the implementation that you mechanically derive from a specification probably is not optimised for your target platform; it does not use design idioms from that platform’s UI, it does not use all of the hardware facilities available, and so on. You either tweak the implementation for the platform (by hiring programmers), or you optimise the compiler for the platform (by hiring programmers). Ugh. Programmers.

Secondly, a specification that is precise enough to turn directly into a functional implementation has many of the features of a computer program anyway. You know who can work with computer programs? Ugh, that is right. Programmers.

So through a combination of coercion—managers weaponised Agile, throwing so many tasks into each short iteration that there is no time for gold-plating—and compromise—programmers stopped reading books about programming—programmers and managers reached an uneasy truce. Programmers would (mostly) only write the software that their employers needed (or pretend to, with gold-plating saved for “corporate open source”), in return for which managers would (mostly) tolerate the programmers’ continued presence (or pretend to, until the next software factory hype cycle).

But now, everything has changed. Now we have a new magic pixie dust we can sprinkle over our projects to make everything beautiful and to get rid of those pesky programmers: AI. Does AI now succeed where computer-aided software engineering (CASE) failed? Can we make a software factory out of LLMs?

Yes, and no. Firstly, I will quickly dismiss the idea that Spec-Driven Development takes us back to the CASE days. This is quick to do because I already made a video on it.

But a software factory is a specific kind of CASE product, and a specific application of specification to the software world. It is a collection of pre-made components, with templates and recipes that an implementor can use to adapt it on to their specific problem. That kind of thing is so much in the wheelhouse of an LLM-based coding assistant that there are two different technical ways to solve the problem.

A software factory vendor could package their factory as an Agent Skill. The SKILL.md file tells the LLM how the software factory is structured, and what to do. Recipes/playbooks are scripts in the scripts/ folder that the LLM runs to fulfil certain tasks. Pre-made components and templates are in the assets/ folder, and documentation, of course, goes in documentation/. To build an instance of the factory software, invoke the skill.

But they could also deliver it as an MCP server. This time, the recipes and playbooks are tools that the LLM uses, and the components, templates, and documentation are resources that the server makes available to the LLM. The server also shares prompts over MCP, providing the same templated interaction with the coding assistant that an Agent Skill would.

Now would this work? Yes, of course it would. The real question is: who would make it work? Who understands how to tweak the factory’s output to meet the specific demands of the organisation? Who knows how to integrate it into the existing system? Who knows how to tailor the configurable components to suit the goals of the specific system you are building? Who knows how to fix problems when the LLM does not quite generate the correct code? Ugh, that is right. Programmers.

Cover photo by Pavel Neznanov on Unsplash.

Of course, this has not happened yet, and it will not likely happen anytime soon.

But to learn the history of programming is to see that every major advance in the field was driven by the quite explicit aim of getting rid of those programmers altogether, in one way or another, and to achieve a degree of control over the quality of the final product.

It is safe to say that such control is an illusion, as all control is.

Let us enumerate some famous examples of technologies that promised to bring some kind of control into the process of programming, or at least to free it from the all-powerful hand of programmers: FORTRAN and COBOL in the 1960s; structured programming and spreadsheets in the 1970s; object-oriented programming and CASE tools in the 1980s; design patterns and UML in the 1990s; Model-Driven Architecture and TDD in the 2000s; DevOps and Agile in the 2010s; and the latest fad, Agentic AI via statistical bullshit machines LLMs, in the troubled 2020s during which these words are being poured.

Given all of these efforts, one would think that software in 2026 would be a flawless product of the human mind, a perfect contraption, reliable in its feature set, and easily maintainable by the teams in charge. Built with safety and usability in mind, with respect for privacy and ecology concerns, and even with aesthetic considerations. Would that not be a safe assumption? Have we not been building software for over 65 years at this point?

(This author will wait for the reader of these lines to stop laughing uncontrollably.)

Of course not. Quite the opposite. If anything, software has bloated to the point where all the common sense that could be safely thrown out of the window has suffered precisely that fate, where every new wave of hype takes the industry into yet another roller coaster tour and where all rationality has long ago left the building.

No wonder many of us are seriously thinking of raising sheep in the Kerguelen Islands, as far away as possible from any software or human beings, for that matter.

(Catches breath.)

The idea of “software factories” is not new, and as many things in our industry, it was an IBM engineer who came up with it: Bob Bemer, one of the original designers of COBOL and ASCII. He published a paper titled “The Economics of Program Production” in annus mirabilis 1968, in which he described the idea of a software factory, outlining three clear goals:

a. Maximizing programmer effectiveness and personnel resources.
b. Minimizing time and costs for original production, changes and checkout.
c. Maintaining the best-conditioned system from a quality viewpoint.

Generation after generation of programming team managers have been trying to optimize these three variables by whichever means required. Developers, like Schrödinger cats aware of the fact that they are in a box with a lethal isotope next to them, have time and again silently boycotted these efforts (for better or for worse), and the resulting patchwork of technologies and approaches has had an effect akin to that of Taylorism in our field.

Precisely, this author made a painful comparison in this magazine almost 5 years ago:

Software workers are the new factory workers of the 21st century; a group of workers whose obesity, deafness induced by earphones worn in noisy open spaces, and carpal tunnel syndrome, are all visual marks of stress and abuse. The invisible ones having mental health issues; burnout, harassment, depression, all conveniently ignored by insurances, managers, and other board members.

And in this new age of LLMs and Agents, they are also the ones that are conveniently laid off, for the sake of efficiency… and also to raise the market price of the stocks of their respective companies. Those CEOs could always use yet another yacht, after all.

Eliezer Talon, in a discussion about yet another modern software factory concept called the “pull request”, wrote that

The problem is that software development organisations are not assembly lines. Most of the effort goes into understanding the problem, validating assumptions, and adapting when we discover we were wrong. Those activities benefit from collaboration rather than isolation.

Bingo. Somehow, even in the age of LLMs, programmers still have a job; if anything, at least to check that the output of those chatbots makes any sense whatsoever. This raises another crucial question, quite uncomfortable for many, about how to train future generations of programmers to have precisely the skills required to distinguish the wheat from the chaff.

As an old man screaming to a cloud, this author thinks that we could still bring a sense of ethics in our future generations of programmers and software engineers, instead of teaching them yet again how to fool an AI interview process to get a job. I thus hope for a management style where control is neither the carrot nor the stick but a healthy consequence of a well-working dialogue between managers and programmers. Maybe it is not too late to dream of that.

Or perhaps, as usual, I am just being too idealistic.

Cover photo by Steve A Johnson on Unsplash.

Hence, this month’s Vidéothèque entry is “The (Short) History of DevOps” by Damon Edwards, a 12-minute video published in September 2012, explaining the early memories of DevOps and how it evolved from 2009 to then. Pay attention to the release date of this video: we are talking about DevOps before Terraform, Docker containers, or Kubernetes.

The video explores the origins and evolution of the DevOps movement, documenting how it transitioned from a niche frustration into a globally recognized IT buzzword. Damon aims to clarify the often-misunderstood roots of DevOps, highlighting key individuals, conferences, and community efforts that shaped its decentralized development. The most important part here is to understand that no individual vendor took part in the creation of DevOps; this is quite an important point.

So the history begins in 2007 in Belgium with a certain Patrick Debois, who experienced deep frustration at his job (we can all relate to him here) due to the constant friction and conflicting workflows between agile development teams (“Dev”) and traditional operations (“Ops”) while working on a data center migration. This disconnect led to a pivotal moment at the Agile 2008 conference in Toronto, where Andrew Clay Shafer proposed a session on “agile infrastructure” (minute 01:34) that nobody attended. Like, literally nobody, except for Patrick. Their resulting conversation spawned a Google group, but the true turning point occurred during the 2009 O’Reilly’s Velocity conference, when John Allspaw and Paul Hammond delivered a famous presentation on “Dev and Ops cooperation” at Flickr, as explained at minute 03:03.

Stuff went fast from that point. Inspired by the Velocity presentation, Patrick Debois organized a local gathering in Ghent, Belgium, in late 2009 to bring developers and systems administrators together, named “DevOpsDays,” a term that was quickly shortened to the hashtag “#DevOps” by attendees wanting to save character space on Twitter (minute 04:42). Somehow, this sparked a global community out of nowhere, leading to more face-to-face meetings in places like Australia and the United States and eventually causing the movement to cross the chasm into mainstream adoption.

In just 3 years, from 2009 to 2012, DevOps became the definitive software factory concept: a set of best practices and activities, mindsets, and (yes) rituals so that software could be put into production not just 2 times a year but potentially 20 times per hour, with better quality and less friction. Ah, the dream.

DevOps is, then, an experience-based, grassroots movement created by practitioners, for practitioners (minute 09:21). It was never designed as a rigid standard, a specific product, or a corporate job title imposed by vendors. Keep that in mind the next time you get to use the Azure DevOps Server console for your project. No, Microsoft did not come up with the name or the concept.

Watch “The (Short) History of DevOps” by Damon Edwards on YouTube.

Cover snapshot chosen by the author.

When you build a Linux kernel (or someone builds it for you), an important step is configuring the build. The project uses a domain-specific language called kconfig to define various parameters and feature settings. You (or the person who does it for you) choose what features you want in the kernel, and what values you want for the other parameters, and those define the way that the build system builds a (not the) Linux kernel for you. The kernel build system is a factory, Linux is a software product line, and the specific Linux kernel you build is a product in the product line.

Or, as Don Batory points out in the important, if somewhat idiosyncratically written, “Science of Software Product Lines”, the output of kconfig is the Linux kernel you might build, if you get lucky. 87% of the configurations you can create using kconfig result in a product that does not even compile. Clearly Linus Torvalds needs to read this book.

Much of the time, software designers think about features and about codebases as orthogonal concerns. Yes, “the business” wants me to add a feature to the code, so what I am going to do is to read the code and work out some changes to make that I think integrate the feature into the existing ball of mud architecture. OK, maybe they want me to soft-launch the UI behind a feature flag, so I will find some places where I can put if(featureIsEnabled) into the code so that the feature gets turned on when the flag is set.

Technically, that product with the feature flags in is really a software product line. Each person gets their own version of the product determined at runtime, based on the state of the collection of feature flags defined for that person. But, like the Linux kernel, the creators of that feature-flag-rich app have not read “Science of Software Product Lines”, so they are not getting the full benefit of decades of research in the area.

Those of us with long memories—or who still build venerable GNU projects like Emacs or GCC from source—remember the “fun” to be had with the GNU autotools, specifically GNU autoconf and GNU automake. The concept was simple: you could make your software both portable, and flexible, by defining macros that configure build settings and enable or disable features. In fact, and perhaps surprisingly, it did not work like that at all. What it did was to inspect the target system and the options someone used to run the script, and define a collection of configuration points that instruct the build system to create different products, with distinct feature sets and internal behaviour. Yes, that is right, a GNU autoconf build system defines a software product line, and none of us had read Don’s book, either. How could we? It was published in 2026.

The typical way that autotools projects configure a software product line is to provide C preprocessor macros that the compiler uses to conditionally include or exclude feature code, switch implementations of routines, or set concrete values for abstract ideas, like the size of a memory region. Batory shows us that the C preprocessor (CPP) is one of the most powerful and capable tools available for creating software product lines—and also one of the most dangerous, as its text-substitution approach readily leaves code in an uncompilable state, particularly when features compose in unexpected ways (hence the dice roll every time you try to configure the Linux kernel). This mess is to the compiler what DLL Hell is to the runtime environment.

His book shows the theory behind slicing software by feature, and composing the code fragments that add features, and the second-level code fragments that ensure two features play nicely when they are both selected. He shows that a feature map is the space of all possible software products that a software product line produces, and that it is finite, even if potentially humungous; the Linux kernel SPL has far more possible configurations than the number of particles in the universe (when I worked at Facebook in 2014, so did the set of feature flags in their mobile apps).

He shows practical tools, like the X15 refactoring engine that uses Java annotations to build and transform SPLs in semantically valid ways. He demonstrates how object-oriented modelling can yield flexible designs that are amenable to supporting SPLs; including novel OO capabilities as in the BETA programming language. BETA is similar to the SIMULA language, but inheritance runs in the opposite way than you are used to. A parent class can inherit behaviour from its subclasses, and include instructions in its method definitions that tell the runtime to invoke the subclass’s implementation of the method. It is no surprise that OOP is a great technique for building SPLs from components, given that Brad Cox showed us how to do this with Software ICs, and how to monetise it with Superdistribution.

By far the most interesting chapter is towards the end, where Batory lists open challenges in SPL research with their complexity, reading like the higher-difficulty “exercises” in “The Art of Computer Programming”. These range from the most modern of 2026 challenges (how to work with SPLs in the LLM era) to the most basic and surprising of fundamental knowledge gaps: nobody has ever provided a scientific basis for believing that modularity is beneficial in software design. Even the most worthy of luminaries, Edsger Dijkstra, axiomatically accepts “the separation of concerns” as a good idea, as if its alternative is something that should be considered harmful with no further thought. This, ironically, in a paper called “On the role of scientific thought”!

Cover photo by the author.

Case in point: “MDA Explained” (2003) by Anneke Kleppe, Jos Warmer, and Wim Bast; and “Aspect-Oriented Software Development with Use Cases” (2005) by Ivar Jacobson and Pan-Wei Ng. Understandably, neither title will immediately make sense to those faithful readers of this magazine; both are, however, connected to the subject of this month, that is, software factories, and are, of course, connected to the renowned “Booch-Jacobson-Rumbaugh” series of books published by Addison-Wesley at the turn of the century.

First, a bit of background. Unlike many other professions, software engineers are usually requested to participate in activities that are explicitly designed to destroy their profession. In the case of the author of these lines, I was working at a major European consultancy company that wanted to standardize the production of J2EE and .NET applications to the maximum possible extent, thus creating one of those mythical “software factories” management gurus had been touting to everyone back in the day. Doing so in 2005 meant, invariably, diving into the world of “Model-Driven Architecture”.

This moniker describes a set of procedures by which architects would be able to design a system completely… just through UML diagrams, or “models” of some kind. Please stay with me. The whole idea being that, with the correct set of use-case, sequence, state, and class diagrams, defined following some very complex and standardized “metamodel” (whatever that was), a translation system would be able to generate the code for a J2EE or a .NET application, or potentially any other language, thus increasing the output of the whole consulting organization, being able to reuse and standardize knowledge across teams, reducing development times, and reaping who knows how many other benefits.

Dare I say that this never worked? Of course it did not. To begin with, the entire idea disappeared because of the lack of involvement of big names in the industry. Neither Sun Microsystems (the inventors of Java, before being gobbled by Oracle) nor Microsoft (who were very happily selling Visual Studio licenses all over the world) seriously considered the possibility of switching from code to diagrams. No other (major) vendor jumped onto this train, ever.

Another problem of the approach was that code has a granularity that a diagram cannot provide, no matter how carefully those sequence diagrams would define the, well, sequence of method calls between objects. Code might be the exception to the rule that says that “an image is worth a thousand words”; a diagram was simply not worth a thousand lines of code.

So that left the Object Management Group (the organization in charge of the standardization of UML, with the somewhat unfortunate acronym “OMG”) struggling to find support, and by 2010 the whole idea of MDA had disappeared altogether, at least from the perspective of this software developer. I have never heard it implemented anywhere, and other hype factors (mobile, the Cloud, DevOps) took over the imagination of developers.

On the other hand, we have Aspect-Oriented Programming. This was yet another major buzzword in the early 2000s, proposing yet another paradigm to separate code elements and to reduce duplication in code. And yes, apart from some very specific use cases and from some very specific platforms that somehow supported it, AOP never really took off as a major approach in the industry. Not even after all of Jacobson’s and Ng’s efforts to teach us how to use Use Case diagrams to model such interactions.

Both books represent valid, very commendable efforts to try to bring order to chaos. In this article we could mention the gazillion books and magazine articles written about “CASE Tools” in the late 1980s and so many other approaches that the industry has tried to bring software factories to life. But the stubborn reality is that, ironically enough, software is better made in workshops than in factories. Maybe it is time for the industry to realize that even in the age of LLMs and Agentic AI, programmers work better in small groups with a certain artisan feeling than in a big, impersonal factory (and this is true even if you use one of those continuous integration pipelines in it).

Meanwhile, kudos to you if you remember MDA and AOP in 2026, fellow old developer.

Cover photo by the author.

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.