It’s not that I like COBOL. I like software that leaves me alone.

If my friends and acquaintances are mistaking me at this point for the illegitimate niece of Grace Hopper, I probably can’t blame them. Someone recently sent me some retro-computing material starting with something along the lines of “as you’re the niece of Grace Hopper”, and given how much COBOL has appeared in my recent experiments, I can understand where that came from.

But I can’t stress it enough: it’s not that I’m now a COBOL fan-girl. In fact, I don’t particularly like programming.

I can read code, I can write code, and over the years I’ve written my share of programs, scripts, patches and glue around other people’s software. But writing software is not what attracts me to computing. I’d rather spend my time researching how something works, experimenting with a system, understanding why it was designed in a certain way, or trying to connect a few apparently unrelated pieces together. Programming is something I do when I need a missing piece and nobody else has made it for me.

Before getting into COBOL, though, let me tell you a little story.

In March 2011 I was in Boston for work and got caught in a snowstorm. I couldn’t leave the hotel for three days and, with a lot of spare time on my hands, I decided to re-learn Clipper and xBase and write my own flight management log using the Harbour compiler. The program is simply called voli, which means “flights” in Italian. Nothing particularly exciting. I used function keys to select departure and arrival airports and the databases were, and still are, plain non-indexed DBF files.

At the time I hadn’t really understood why I liked doing things that way. I hadn’t done all the “interior” research about my relationship with computing that I have done more recently. I just knew instinctively what I liked.

That exact program is what I still use today, fifteen years later.

Of course I’ve changed a few things over time. I’ve added features when I wanted them and fixed the occasional bug, but fundamentally it is still the same little application doing the same job with the same boring data files. Most importantly, I haven’t had to maintain it simply because the world around it decided to change. I wrote it because I wanted a flight log, not because I wanted a fifteen-year relationship with a programming ecosystem.

And that is perhaps the whole point of this article.

I like computing. Programming, not so much.

What I actually enjoy is understanding complex systems. Networking, operating systems, storage, databases, protocols, old computers, new computers, how all those things evolved and how they fit together. I like taking the Lego bricks that already exist and working out how to connect them. If one little brick is missing, I’m perfectly capable of crafting it myself, but making that missing piece is the means to an end, not the part I’m particularly passionate about.

This is also why I can quite happily make a patch while saying that I don’t like programming. A bug gives me something to investigate. Why does this happen? Where does it break? What assumption did someone make that isn’t true on this operating system or in this particular situation? Finding that can be interesting, and writing a patch is simply the last part of solving the mystery.

The same applies to proofs of concept. If I wonder whether something can be done, I may be perfectly happy to write a small program to prove that it can. Once the question is answered, however, my enthusiasm tends to evaporate rather quickly. If that proof of concept now needs to become a real application, with all the features, tests, packaging, documentation and long-term maintenance that come with it, I’d much rather give it to a professional developer who actually enjoys doing those things.

Splendid. It’s yours. I’m going over there to investigate something else. :)

It’s not very different from my day job. I have always preferred architecture to daily operations and support. Designing a system gives me questions to answer: how should these pieces fit together, where should the data live, what happens when something fails, what assumptions are hidden in the design, and can we make the whole thing simpler? Once the machinery is understood, operating the same machinery every day is important work, but it’s not the part that keeps my curiosity alive.

Programming is much the same. I don’t mind writing code to answer a question. I become much less interested when the code itself becomes the question.

Please stay written

Many years ago I also wrote my own accounting software because my billing model didn’t fit any existing application. Calling it an application might be slightly generous. It was mostly a collection of Python scripts around a database, with a PHP frontend generated using SQL Maestro.

I really liked early Python 2.x. To me it felt like a sort of bash on steroids: still quick enough to write without too much ceremony, but with proper database support and a huge collection of useful libraries. It fitted very well with the way I use programming, which is mostly to glue things together and get on with something else.

On the database side I used SQLAlchemy. The slightly amusing part, looking back at it now, is why I chose it. I wasn’t particularly interested in clever abstractions or object-relational mapping. I chose an abstraction because I thought it would make database handling boring. Instead of writing SQL all over the place, I could use one interface and, supposedly, stop thinking about the details underneath it.

That turned out to be a bad choice for what I wanted.

As SQLAlchemy evolved, interfaces changed and functions were deprecated. None of the changes were rocket science to deal with, and this isn’t meant as criticism of SQLAlchemy. Software evolves, and projects have perfectly valid reasons to improve their APIs. The problem was simply that I didn’t want to be part of that evolution.

My accounting requirements hadn’t changed. The database was still doing what databases do. The code had already solved the problem I wrote it to solve. Yet I was spending my time modifying working software because the abstraction I had deliberately chosen to protect me from change had itself changed.

In retrospect there is something rather funny about choosing an abstraction because I didn’t want to depend too much on SQL, only to discover that boring old SQL would probably have been the more stable contract.

And that’s the kind of thing that annoys me to hell.

If I write some software today, I’d like the reasons for touching it ten years from now to be that I found a bug, I want to add something, or the actual requirements have changed. I don’t particularly want to revisit it because a library changed its interface, a language decided that yesterday’s perfectly valid construct is now deprecated, or the environment underneath it moved enough that the program has to be adapted simply to continue doing exactly what it did before.

Ideally, I want to code once and almost forget about it.

Software should be allowed to stay finished.

And somehow I ended up with COBOL

Which finally brings me back to COBOL.

It’s not that I suddenly discovered a passion for DIVISIONS, nor am I planning to spend the rest of my working life writing business applications in COBOL. Given my complicated love-hate relationship with programming, that would be a rather strange career choice.

COBOL just happens to tick quite a few boxes that matter to me.

The major one is stability. The grammar doesn’t reinvent itself every few years, and code written a long time ago has a very good chance of still meaning the same thing today. If I write something once, unless I want to add functionality or fix a bug, there is a reasonable chance that I can simply leave it there. Clipper and xBase give me much of the same feeling, which probably explains why that little flight log from Boston is still alive and perfectly happy after fifteen years.

COBOL is also ridiculously portable. Compilers have existed for an enormous number of operating systems and processor architectures. There is even a COBOL compiler for the Commodore 64, because apparently someone decided the C64 desperately needed business logic. Of course portability has limits. Screen handling, indexed files and platform-specific facilities can make moving a program more complicated, but if the core logic and data formats are chosen sensibly, moving the program itself is usually possible.

The data side matters to me just as much. I like understandable and documented data formats, whether that’s a DBF file, a sequential file, a database table or something deliberately simple like the approach I’ve been taking with TULIP/400. Applications come and go. I want the data to remain understandable even if the original program eventually disappears.

I also like that COBOL fits quite naturally with the sort of small terminal applications I tend to write. Forms, records, files, business logic and a TUI are enough for a surprisingly large number of things I need. The programs can be small, require very little memory and run ridiculously fast on modern hardware. That’s not my main reason for using it, but I certainly don’t mind software that doesn’t require half a gigabyte of runtime before it can ask me for a date and update a record.

And finally, there is the syntax. COBOL is verbose and some of its structure feels rather ceremonial, but it is also understandable. I can look at a piece of code and generally follow what it is trying to do. I still have the usual inertia when faced with an empty source file, and tea and biscuits may have to provide some encouragement before the first few lines appear, but it feels much less intimidating to me than starting a program in C, Rust, Go or one of the other languages that require considerably more planning before I can get to the bit I actually care about.

This isn’t really about COBOL, though. It’s the same reason I like Clipper and xBase, and why Perl or early Python suited me so well. It’s also part of what I like about IBM i and DOS, and to some extent the simpler Unix and Linux environments I grew up with. They all give me, in different ways, the feeling that something I build today has a decent chance of remaining useful without constantly demanding my attention.

Boring is good when the software itself isn’t what I want to spend my time thinking about.

That doesn’t mean software or operating systems should never evolve. New hardware appears, security requirements change and sometimes an old interface genuinely does need to disappear. But compatibility has value too, and I increasingly worry when modern operating systems casually drop old hardware or long-standing interfaces. Every time the platform moves underneath an otherwise perfectly useful program, something that was finished, becomes unfinished again.

Sometimes that is a price worth paying. Sometimes it just gives me another job I never asked for.

If somebody came along tomorrow with another compiled language with a stable grammar, plain and understandable syntax, good terminal support, simple database access, documented data formats, a small footprint and a serious attitude towards backwards compatibility, I’d probably be interested. It doesn’t need to be COBOL. It doesn’t even need to be old.

I don’t care very much about the language itself. I care about what happens after I’ve written the program.

I want to spend my time researching things, understanding systems, trying strange ideas and seeing whether something can be made to work. If some code is required along the way, that’s fine. I’ll write it.

Then, ideally, I’d like it to keep working while I go and investigate something else.

So no, I’m not really a COBOL fan-girl.

It just happens that COBOL is remarkably good at leaving me alone.