This is pretty neat, I'm not a huge COBOL fan but actually got paid once to write code that generated outreach mail for political correspondence using voter registration data. For that, it worked really well and I could certainly appreciate the appeal for business process work.
Weirdly though, I get put off by their name, as my brain wants to pronounce it with a long o sound instead of the 'eh' sound from 'works' (werx as a spelling works better for me than worx, no pun intended). It has me wondering if people pronounce 'Torx' screws as 'Turks' screws.
As for the 2nd "o", I don't know. Whatever the case, you should say the entire word slowly and loudly since they are all capital letters.
Like, imagine yourself as an inept alien spy. You walk up to a group at a party and interrupt someone in the middle of their story. "HELLO, I AM BOB FROM CORPORATE. I PROGRAM IN COBOL. HOW ARE ALL OF YOU TODAY?"
I've heard that GCC is notoriously difficult to create a front end for and that is one of the reasons people liked using LLVM. Has this improved recently or are people just powering through the internal code to get this working?
This was one of LLVM’s explicit design criteria, but with its long head start gcc still has more front ends. It’s had so many that some (like chill) have even been removed! It’s not extraordinary that someone would use gcc as a back end for a new language.
I have only looked at the GCC Fortran frontend. I would not say it is necessarily difficult but rather very ad-hoc and disconnected from the rest of gcc. I don't see many tools for specifying a grammar or tokens. Instead, there are a lot of constructs custom-written to handle Fortran. Looking around, the Go and Rust frontends feel equally disconnected.
I'm told that you eventually make your way to the "GCC IR", but it seems like you are largely on your own with how to get there.
I did not invest a lot of time here, so I could be wildly off base, but thought I'd at least try to give a very-slightly-hands-on perspective.
$ rpm -q gnucobol
gnucobol-3.2-1.el9.x86_64
$ rpm -qi gnucobol | tail -2
COBOL compiler, which translates COBOL
programs to C code and compiles them using GCC.
It will output intermediate C; one interesting thing is that the MOVE directive is mostly turned into memcpy().
I have been able to get the Oracle Pro*COBOL preprocessor to fully compile and run a demo database connection that connects to the "scott/tiger" schema and runs simple queries. Oracle packages both Pro*C and Pro*COBOL here (look for " Additional files for Pro*C and Pro*COBOL"):
Interesting, I remember it be harder than that. But, when I had to write a basic parser during the Y2K storm, I was still a bit green in my programming skillsets.
Hmm, yea. I guess I'll have to take a look and see how they handled it. Thanks for the link!
Pretty surprised to see this given GnuCOBOL (previously OpenCOBOL) has been part of the GNU project for a little while. https://gnucobol.sourceforge.io/
It makes sense as OpenCOBOL isn't part of GCC as a front-end, it generates C code that is compliant to various COBOL standards and extensions. That C code can subsequently be audited and/or compiled with GCC/clang.
How much COBOL runs on platforms other then the Mainframe? My limited COBOL experience was while working for a Mainframe software vender. I have not scene anything about people running COBOL in production on non Mainframe platforms, doesn't mean it isn't happening though.
Weirdly though, I get put off by their name, as my brain wants to pronounce it with a long o sound instead of the 'eh' sound from 'works' (werx as a spelling works better for me than worx, no pun intended). It has me wondering if people pronounce 'Torx' screws as 'Turks' screws.