Ask HN: Has anyone here learned COBOL for fun?

I learned COBOL in college just to learn it, and I loved the verbosity of it. Verbosity was kind of the point: if you name your variables properly, you have self-documenting code.

Yes, the processing COBOL does is restricting, but then my first full-time programming job was two and a half years writing RPG II code. COBOL would have been an upgrade.

It's on my list of languages to learn, but I haven't gotten to it yet.

My first job was supporting a custom application running in UniVerse on Solaris. It originally ran on a Prime mainframe and UniVerse was one of the ways you could run this type of software on a modern system. I really enjoyed working in the Pick MultiValue environment. In many ways, this was a NoSQL database from before NoSQL was a big thing.

I don't work in this world anymore, but I've been playing with ScarletDME (a fork of OpenQM, another MultiValue database, from before they closed the source) and seriously enjoying it.

As a result of this first job I've got a special place for "old" programming languages/environments. My dream retirement job is to work for either the CRA or IRS supporting their old systems. Between the complexities of income tax and the old-school code that can never be retired I think I'd love it.

i wouldn't say fun, but it is easy. back in the 1980s i had to write a couple of cobol programs to unpack some dec10 isam files so that i could import them into our spiffing new ibm 4381 4gl (nomad/2 if anyone is interested). i read a cobol tutorial in the morning, and wrote the programs in the afternoon. only problem was my spelling - i couldn't spell "environment" as in cobol's ENVIRONMENT DIVISION.

and as others have observed, it's the infrastructure (JCL, TP monitors, etc.) which is the real problem.

Yeah, I learned COBOL for sort-of-fun (in the sense that it wasn't strictly for a paid gig) a long time ago. It went pretty well, in that I learned that, while it isn't a fun language in any sense of the word, it Just Works and even adheres to the revered Unix principle "do one thing, and do it well" in most production situations.

Most COBOL programs have a very well-defined batch-oriented flow: take this file, process it, then output these file(s) within N hours. Reliability is paramount: batches often run overnight, and you don't want operators getting angry with you. And there is an entire ecosystem, all consisting of proprietary (and expensive) IBM solutions like CICS, that make CRUD apps (which, admit it, is like 80% of all software...) pretty much a piece of cake.

The downside of all this, is that you're very much limited to whatever your vendor allows, that progress is glacial, and that innovation is pretty much unheard of (since that might break the batch, which is... a mortal sin). And, like with the Unix philosophy, orchestration of all those single-minded processes becomes an issue after a (short) while.

If anyone were to ask me whether they should "learn the language", my answer would be an unqualified no, unless it's for a specific paid assignment. There are no unique ideas hiding anywhere in COBOL that are absent from more modern (and more 'fun') languages.

But does it matter to learn the language paradigms and orchestration requirements? Sure: you may land a good gig if you understand where AS400s/i-Systems/whatever fit in, and it may give some insight into where things like Docker and K8S are coming from.

My wife made a COBOL mortgage calculator back in college for her CS programming languages course. She said it was more verbose than she would have liked, but it worked nonetheless.

We keep joking maybe she should apply for one of those high paid legacy COBOL jobs that make their way into the news cycle now and then.