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

[Wim Niemans]

Patrick,

respect for your initiatives ! Though the basis to do so by adding trendy words 
isn't the right argument.

One aspect, as others emphasized, of the use of Cobol is the language being 
standard.
Another aspect, to my opinion, is that its origin is some real different from 
younger languages.
To make that clear I like to speak about Cobol Text as opposed to (java or C) 
Source Code.

Most OO features of modern languages, at least the more advanced ones, are 
often implemented by a pre-processor that processes so-called @ notations.
It is common to generate documentation from these @ notations. I am not aware 
that such is ever done for Cobol (with a reason ;-)).
Than, you have to realize that these modern languages did eliminate the 
persistence layer a system should have.
Cobol is build around such persistence layer with OS native features. 

Forking, neutral, friendly or hostile, well, give it a try.
And when you are at it, add some decent features, like a built-in CGI gateway 
or a interface to a messaging-bus.

Wim

Op 27 jun. 2013, om 00:34 heeft Patrick het volgende geschreven:

> 
>> 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
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list