My recent article observing that Python is slowly becoming more like Perl received much more attention than I had imagined. Most of the attention was from Python developers with almost zero push back.

The love I have for Perl is rooted in my first job where I was introduced to Unix systems. The company I joined had embraced Unix (and C) across the board, creating an extremely profitable company out of practically nothing. For decades, with no competition and reasonable licensing fees for DG/UX, HPUX, SCO/Unix and eventually RedHat Linux they literally printed money.

By collecting public judgment records and certifying the search results they slowly created a multi-million dollar business. Using ETL tools and a clever search engine written in C they cruised along until they were eventually sold for $80 million dollars (back when that was a lot of money).

When I joined the company, I was fairly adept at C programming but had only dipped a toe in the Unix world as a consultant for a company that didn’t mind me learning on their dime. It didn’t take me long to look at my new company’s attempts at ETL using C to realize there had to be a better approach. Soon I was knee deep in “Learning Perl”, “Programming Perl”, “Mastering Perl”, and any other O’Reilly Perl book I could find.

Demonstrating that Perl was a superior ETL tool than C is not hard. It is especially easy when your scripts can connect to an Oracle database, update and insert rows in half a dozen lines of code. Compare that to Oracle’s Pro*C nightmare and you have every developer in the company borrowing your “Programming the Perl DBI”.

ETL was only one way to get Perl a foot in the door. It got more interesting. The company started looking at the emerging era of web applications and realized that their TTY interfaces over slow modem connections allowing clients to enter orders was doomed. With many of their back-end services accessible by TCP clients, I was soon translating their C clients into Perl clients and writing web applications.

The trajectory is of course predictable. Once you pick up Lincoln Stein’s “Network Programming with Perl” you’ll soon be reaching for Stevens’ UNP volumes 1 & 2 to complete your curriculum. And if they have APUE (“Advanced Programming in the Unix Environment”) lying around it might make for some good night time reading too. Incidentally, when the company was sold and the developers were all writing Perl (and eventually Python) the folks who had purchased those books were long gone. Someone decided it was a good idea to cleanup some bookshelves. The Stevens’ classics were unceremoniously tossed in a box next to “The Internet for Dummies”. Luckily I saved them from the indignity of a landfill full of seagulls. They’re now sitting comfortably on my shelf next to “Unix Text Processing” and “Unix Power Tools”.

Here’s the punchline…

Perl is how I learned Unix.

So here I am nearly 30 years after joining that company, still puzzled over the story of Perl’s decline. We live in a containerized world where Linux has unequivocally won the infrastructure war. Every Docker container, CI/CD pipeline, and Kubernetes pod is running a Unix-like environment.

Yet, ironically, interest in Perl - the language purpose-built by a linguist and systems programmer to be the ultimate Unix glue - has waned just as its native environment won the servers war (and may one day be declared the victor on the desktop as well).

We have taught a generation of cloud-native engineers who are incredibly adept at deploying infrastructure, but who are, for the most part, insulated from the operating system that runs it. Modern languages like Python, Node, or Go are designed to abstract the OS away (special finger wag at Java for creating their own OS). They treat the kernel as a nuisance to bypass rather than a machine to understand. This works perfectly until a leaky abstraction hits. When a container runs out of memory, file descriptors, or an IPC pipe deadlocks, or a parent process starts spawning zombies, the modern developer is suddenly left staring at a raw POSIX operating system they do not understand.

When thinking about a tool’s ability to navigate this reality, I use a metric I call the “Distance from Stevens” - a reference to those W. Richard Stevens seminal books that I saved from the dump.

C has a distance of zero; it is the language of the kernel, but using it means getting bogged down in pointer arithmetic and memory allocation. Modern scripting languages have a massive distance, hiding the mechanics of fork, exec, and stat behind friendly, object-oriented wrappers.

Perl sits in the absolute sweet spot. It exposes the underlying Unix system calls using the exact same names, arguments, and return values as the C standard library, but it strips away the accidental complexity of C memory management. It forces you to understand inodes, bitwise permission masks, and process genealogy. It’s how I could create a TCP client in Perl by merely looking at the C equivalents.

Instead of being viewed as a relic, Perl’s unapologetic closeness to Unix makes it the perfect diagnostic and pedagogical tool for the cloud era. Which leads to an interesting crossroads for the language’s future.

Can Perl resist the pull to be something it is not, embrace its core principles and design, and be discovered again by a new generation of software developers who are now steeped (even if they don’t know it) in Unix?

It will only take one or two professors at some prestigious university to realize the value of using Perl as a way to teach Unix fundamentals for Phoenix to rise again. And the students coming out of that environment will be much better engineers than those who just learn how to write a Django web application using AI.