I paid for high school and university writing Cobol, so I'm strangely interested in the project. Seems like life has come full circle for me :).
Aldy On Mon, Mar 14, 2022 at 9:35 PM James K. Lowden <jklow...@schemamania.org> wrote: > > https://git.symas.net:443/cobolworx/gcc-cobol/ > https://github.com/Apress/beg-cobol-for-programmers > > Greetings, gcc! We come bearing gifts! > > When you set your clock ahead an hour yesterday, you might not have > realized you set your calendar back to 1985. There's a new gcc COBOL > compiler. We call it: gcobol. > > On the books, we have 1 man-year invested: two full-time > programmers since October 2021. > > We have so far compiled just over 100 programs from the examples in > "Beginning COBOL for Programmers", by Michael Coughlin. We are near the > end of that phase of the project, and expect to have ISAM and > Object-Oriented Cobol features implemented in the next few weeks. We > are working on compiling the NIST COBOL test suite, which we expect > will take a few months to complete. We have begun work on gdb, too, > and hope to have it working by year end. > > Our project should not be confused with GnuCOBOL > (https://savannah.gnu.org/projects/gnucobol). That project is a Cobol > translator: it compiles Cobol to C, and invokes gcc to produce > executable code. Our gcobol compiler is (currently) a fork of gcc. It > implements a gcc frontend for Cobol and (obviously) invokes the gcc > backend to produce executables. (We have a friendly relationship with > GnuCOBOL, and its maintainer supports our undertaking.) > > Ours should also not be confused with prior efforts to create a gcc > Cobol compiler. Others have tried and failed. Failure wasn't an > option for us. I won't say it was easy, but here we are. > > Eventually, if the gcc maintainers are interested, we would like to > pursue full integration with gcc. For the moment, we have questions > we're hoping can be answered here by those who ran the gauntlet > before us. Given the state of the internals documentation, that seems > like our best option. We've been rummaging around in the odd sock > drawer for too long. > > If you're like me (like I was), your visceral response to this > announcement can be summed up in one word: Why? > > The answer is as easy as it is trite: the right tool for the job. > > I wouldn't write an operating system in Cobol. But I wouldn't write > one in Python or Java, either. Cobol has a niche no other language > occupies: a compiled language for record-oriented I/O. > > That might sound strangely specialized, but it's not. Record-oriented > I/O describes, I would argue, nearly *all* applications. Yet, since the > advent of C, nearly all applications have relegated I/O to an external > library, and adopted the Unix byte-stream definition of a "file". > > If you've written a CGI web application, you know what I'm talking > about. Cobol eliminates a lot of gobbledygook by reducing free-form > run-time variables to compile-time constants. > > That's the rationale, and it's not just a theory. Cobol is alive and > kicking. Estimates vary, but they all say north of 100 billion lines > of Cobol are still in use, with millions more written every year, even > now, in the 21st century. Odds are your last ATM transaction or credit > card purchase went through a Cobol application. > > There's another answer to Why: because a free Cobol compiler is an > essential component to any effort to migrate mainframe applications to > what mainframe folks still call "distributed systems". Our goal is a > Cobol compiler that will compile mainframe applications on Linux. Not > a toy: a full-blooded replacement that solves problems. One that runs > fast and whose output runs fast, and has native gdb support. > > I am happy to debate the lunacy of this project and the viability of > Cobol, either here or off-list. Today, we want to make the project > known to those in the technical community who might most want to know > what we're up to, and explain why we'll be asking the questions we're > asking. > > Also, if you want to give it a whirl, please don't hesitate. We're > happy to help, and expect to learn something in the process. > > Thank you for you kind attention. > > --jkl > >
