Re: @tfb This is why
I've been saying this for some time about COBOL. (Oh and I work with FORTRAN in HPC quite often)
People make a big deal about COBOL programmers being in short supply and that it's an antiquated language. Honestly though, what makes programmers really confused about it is that you don't really write programs in COBOL, it's more of a FaaS (Serverless, function as a service) platform. You write procedures in COBOL. The procedures are stored in the database like everything else and when a procedure is called, it's read from the database and executed.
The real issue with "COBOL programmers" is that they don't know the platform. The platform people are usually referring to when they say "COBOL" is actually some variation of mainframe or midrange computers. Most often in 2020, they're referring to either IBM System/Z or they're referring to IBM Series i ... which is really just a new name for what used to be AS/400.
The system contains a standard object storage system... or more accurately, a key/value store. And the front end of the system is typically based on CICS and JCL which is job control language. IBM mainframe terminals (and their emulators) have a language which could be kind of compared to HTML in the sense that it allows text layout and form entry as well as action buttons like "submit".
Then there's TSO/ISPF which is basically the IBM mainframe CLI.
What is funny is that, many of us when we look at AWS, all we see is garbled crap. They have a million screens and tons of options. The same is said for other services, but AWS is a nightmare. Add to that their command line tools which are borderline incomprehensible and well... you're screwed.
Now don't get me wrong, if I absolutely must use AWS, it wouldn't take more than watching a few videos and a code along. I'd probably end up using Python even though I don't care much for the language. I'd also use Lambda functions because frankly... I don't feel like rolling my own platform from scratch. Pretty much anything I'd ever need to write for a business application can be done with a simple web server to deliver static resources, lambda functions to handle my REST API, and someplace to store data which is probably either object storage, mongodb, and/or some SQL database.
Oddly, this is exactly what COBOL programmers are doing... and have done since 1969.
They use :
- TSO/ISPF as their command line instead of the AWS GUI or CLI tools.
- JCL to route requests to functions as a service
- CICS (in combination with a UI tech) to connect forms to JCL events as transactions... instead of using Amazon Lambda. Oh, it's also the "serves static pages" part. It's also kind of a service mesh.
- COBOL, Java or any other language as procedures which are run when events occur... like any serverless system.
It takes a few days to learn, but it's pretty simple. The hardest part is really learning the JCL and TSO/ISPF bit because it doesn't make sense to outsiders.
What's really funny is that IBM mainframes running this stuff are pretty much infinitely scaleable. If you plug 10 mainframes in together, they practically do all the work for you since their entire system is pretty much the same thing as an elastic Kubernetes cluster. You can plug in 500 mainframes and get so much more. The whole system is completely distributed.
But like you're saying FORTRAN is its own entire platform/ecosystem is entirely true. Everything you would ever need for writing a FORTRAN program is kind of built in. But I will say, I would never even consider writing a business system using FORTRAN :)
Biting the hand that feeds IT
