A functional language that compiles to COBOL. The abstraction layer doesn’t change what runs underneath.
A developer who goes by "Voodoo Child" just dropped something in my LinkedIn comments that stopped me mid-scroll.
He showed a functional language – modern, elegant, mathematically pure – compiling to COBOL as its target backend. You can see the original exchange here.
Jimi Hendrix would have appreciated the irony. The most rebellious act in programming turned out to run on a 60-year-old IBM mainframe.
His caption: "The universe has come full circle."
He’s right. But I think the circle is bigger than he realised.
For those who don’t follow compiler theory: a compiler takes source code written in one language and translates it into another language that actually runs.
Most compilers target machine code, bytecode, or C.
Someone built a compiler that targets COBOL.
Which means: you write elegant functional code. The compiler thinks for a moment. Out comes 300 lines of WORKING-STORAGE SECTION, PIC clauses, PERFORM statements, and PROCEDURE DIVISION.
Here is the actual output. Real COBOL, generated by a functional language compiler, shared by Damian Tedrow ("Voodoo Child"):
IDENTIFICATION DIVISION.
PROGRAM-ID. FACTORIAL.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-ABS-X PIC S9(18).
01 WS-ABS-RET PIC S9(18).
01 WS-MAX-X PIC S9(18).
01 WS-MAX-Y PIC S9(18).
01 WS-MAX-RET PIC S9(18).
01 WS-FACTORIAL-N PIC S9(18).
01 WS-FACTORIAL-RET PIC S9(18).
01 WS-RESULT PIC S9(18).
01 WS-TEMP PIC S9(18).
01 WS-TEXT-RESULT PIC X(256).
PROCEDURE DIVISION.
ABS-PARA.
MOVE WS-ABS-BRANCH-2 TO WS-ABS-RET
MAX-PARA.
MOVE WS-MAX-BRANCH-5 TO WS-MAX-RET
FACTORIAL-PARA.
MOVE WS-FACTORIAL-BRANCH-7 TO WS-FACTORIAL-RET
MAIN-LOGIC.
MOVE 10 TO WS-FACTORIAL-N
PERFORM FACTORIAL-PARA
DISPLAY WS-FACTORIAL-RET
STOP RUN.
The mainframe will compile and run this without complaint. It does not know or care that no human wrote it.
That COBOL then runs on a mainframe. Processing transactions. Moving money. Updating records.
The functional programmer never touched COBOL. The COBOL ran anyway.
There is a principle in computing: abstraction layers let you ignore what’s below. You write Python, you don’t think about C. You write C, you don’t think about assembly.
This is largely true and enormously useful.
But there is a limit.
The abstraction layer doesn’t change what actually runs. It doesn’t change the performance characteristics of what runs. It doesn’t change the operational requirements of what runs. And it doesn’t change who is responsible when what runs stops running at 3:17 AM with 847 employees waiting to be paid.
The abstraction layer is real. The COBOL is also real. Both things are true simultaneously.
There is a recurring narrative in technology: mainframe is legacy. COBOL is dying. The future is cloud-native, microservices, functional programming, Rust, whatever came out last Tuesday.
Meanwhile:
Every time a modern application integrates with a bank’s payment system, queries a legacy insurance database, or processes a government benefit payment – somewhere in that call chain, COBOL is running.
The modern developer doesn’t see it. The abstraction layer is doing its job. But the COBOL is there.
Voodoo Child’s compiler just made that visible in a way that’s impossible to ignore.
I am not arguing that every developer should learn COBOL.
I am arguing that the boundary between "modern" and "legacy" is much blurrier than most developers think.
The functional programmer writing elegant recursive functions is closer to mainframe than they realise – not because mainframe is catching up to them, but because their code, somewhere in the stack, might end up running on infrastructure that has been in production since before they were born.
The people who understand both sides of that boundary are increasingly rare and increasingly valuable. Not because COBOL is glamorous. Because the systems that run on it are critical, and the number of people who understand them is shrinking faster than the systems themselves.
The mainframe doesn’t care how the COBOL was generated. It doesn’t know whether a human wrote it or a compiler did. It doesn’t know whether the developer considered themselves a functional programmer or a systems programmer or a Hendrix fan.
It just runs the batch job.
That indifference is the point. The mainframe has been indifferent to programming trends since 1964. Assembler, PL/I, fourth-generation languages, object-oriented programming – the mainframe ran COBOL through all of it.
It will run COBOL generated by functional language compilers too.
The universe has come full circle, as Voodoo Child said.
But the mainframe was always at the center.
AI is writing COBOL now. Functional languages are compiling to COBOL. The abstraction layers keep multiplying.
Underneath all of them, the same systems run the same transactions they have been running for sixty years.
You might be a COBOL programmer whether you know it or not.
The mainframe doesn’t care either way. It just runs the job.
Also in this series: AI Writes the Code. Who Talks to the Machine? · Why Mainframe is Different – The Execution Graph Problem