[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Announcement: gcobol
From:       Aldy Hernandez via Gcc <gcc () gcc ! gnu ! org>
Date:       2022-03-30 18:16:25
Message-ID: CAGm3qMUR3swuaN7a=yY-O7y0HFwOZ7B2WRkfgZEtxZGWNwy5Fg () mail ! gmail ! com
[Download RAW message or body]

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
<jklowden@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
>
>

[prev in list] [next in list] [prev in thread] [next in thread]