Comment by brightball

Both Fortran and COBOL will be here long after many of the current languages have disappeared. They are unique to their domains viz. Fortran for Scientific Computing and COBOL for Business Data Processing with a huge amount of installed code-base much of it for critical systems.

There are many in-house tools (say at banks) where Java code generates... COBOL. It's wild: in the video you linked it's explained COBOL was meant for machines that don't exist anymore so COBOL is running inside emulators.

So you have Java code, generating COBOL code, that's then run on an emulator emulating an old IBM system that was meant to run COBOL. It's just wild.

Some of the tools are even front-facing users (bank employees): at times you can still see at some banks an employee running an app in a monochrome green-on-black text terminal emulator that is basically COBOL.

It's weird, just weird. But legacy code is legacy code. And if you think COBOL's legacy is bad, Java is going to dwarf COBOL's legacy big times (for Java is typically used at the kind of places that still use COBOL and it's used way more than COBOL).

So in the future, heck, we may have a new language, generating, inside an emulator emulating current machines/OSes, Java code that is going to be code generating COBOL code (!), that's then going to be run in an emulator.

First of all, that conference is right down the road from me, and I never knew about it. So, thanks for sharing!

My first job was working at a credit union software company. I designed and built the front-end (windows applications, a telephone banking system, and a home-banking web thing) and middle-tier systems (VB.NET-based services). The real back-end, though, was an old COBOL system.

I remember helping the COBOL programmers debug some stuff, and it was just so wildly foreign. My degree is in theoretical comp sci, and I'd seen a lot of different languages, including Prolog, various lisps and schemes, SQL, ADA, C++, C, Pascal, various assembly variants, but COBOL was simply unique. I've often wondered what ideas COBOL got right that we could learn from and leverage today in a new language.

I do remember our COBOL mainframes were really fast compared to the SQL Server layers my middle-tier services used, but I also remember looking at it and thinking it would be a giant pain to write (the numbers at the front of every line seemed like tedium that I would probably often get wrong).

In my experience working with large financial institutions and banks, there is plenty of running COBOL code that is around the average age of HN posters. Where as a lot of different languages code is replaced over time with something better/faster COBOL seems to have a staying power in financial that will ensure it's around a very very long time.