gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] IS PUBLIC, IS PRIVATE, enhanced COPY


From: Patrick
Subject: Re: [open-cobol-list] IS PUBLIC, IS PRIVATE, enhanced COPY
Date: Wed, 26 Jun 2013 18:34:07 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6


To answer the reserved-word question first, you must learn to
misspell. For example instead of date use the word ddate or my-date. If
you want to do OO IMO you are better served by using a language built on
that format from the beginning. There are lots of them. In the words of
Lt. Cdr Grace Murray Hopper (I am quoting from memory) "I don't ask
COBOL to do the work of FORTRAN or FORTRAN to do the work of COBOL."
She said this long before we had Python or Ruby or whatever.

Open Source COBOL is built to the COBOL-85 standard with some bits and
pieces of the COBOL-2002 standard added. But all of Open Source COBOL is
per one standard or the other. This differs from most commercial
compilers which have nonstandard extensions for gui screen handling
etc.

The powers that be that build the COBOL standard keep trying to do what
you are trying to do--turn COBOL into something that competes with OO
languages. This is IMO a foolish endeavor bound to fail. There is
enough functionality to do most business tasks already in COBOL-85.
I say most because I have just asked for a workaround to go from julian
to year-month-day calendar date format. Open COBOL (and presumably the
standard) provides a half dozen function routines for dates but none
that do what I am looking for, alone or in combination. I may have to
write an ugly sub-program to do it. But it will be pure COBOL according
to the standard of course.

Hi John

Thanks for answering my post.

It looks like we are not agreeing but I think we actually are.

I spent a lot of time trying to get my post right but as per usual I probably sent the wrong message.

I think Cobol 85 is already very good and I don't personally want much of anything from the Cobol 2002 OO part of the standard.

My feeling is that with just some alternative names and some good examples, Cobol 85 could be made much more appealing to a generation that thinks the language is something horrible, when it is not.

Open Cobol is already standards compliant and adding non standard stuff to it will not go down well with the community, which is why I am proposing a friendly fork. A near identical fork might be useful as there may be many people aside from you and I that think the standards body is not taking the language in the right direction.

And yes, an application does not have to be written in a single language, OO from the ground up like Ruby might be just the thing for some applications.



Have a good day-Patrick




reply via email to

[Prev in Thread] Current Thread [Next in Thread]