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

[Patrick]

Hi Mike

Thanks for responding to me.

So Cobol certainly has been successful.

However this is one of the parts I was afraid to mention in my original 
post and am nervous once again....

Is Cobol successful now? Certainly there is still lots of code in use 
but is it from new code bases....

I bet I am the youngest person on the list and I am surely the silliest 
and biggest day dreamer and I am 37! I am not young.

I like Ruby but I never end up writing anything in it. It was one of 
many languages I just studied but never used.

I did spend time on the Ruby list and it's a totally different scene. 
There are nice people there just like here but my guess is the average 
age is generations younger. I was on the PHP list too and I've seen more 
maturity in a kindergarten class, there where lots of kids that just 
like fighting.

If Cobol "as-is" is dying(perhaps slowly) then would it not make since 
to have old implementations but also new implementations that are 
designed to survive in a world where terminology is set by Java, C++, 
Python, etc? Hence the idea of a friendly but co-operative fork.

I also think it's great that Cobol generates intermediate C. I really 
wish GNAT Ada did this too, I had many problems with it as it can only 
play nice with C with a lot of work.

-Patrick


On 13-06-26 05:59 PM, Michael Anderson wrote:
> Patrick,
>
> I appreciate your enthusiasm, and I also agree with John!
>
> Cobol has been doing a reliable job for over a half-century, because it
> is slow to change.
> Note the long list (hundreds) of deprecated features in Java and similar
> languages, as compared to COBOL's 11 things deprecated.
>
> OpenCobol has some fundamental benefits compared to other Cobol compilers.
>
> String function not available in other compilers:
>       concatenate
>       substitute
>       trim
>
> OpenCobol is closely married to the C compiler:
>       I write C code to be linked into my Cobol, to do things that Cobol
> should NOT be doing.
>       I use 'cobc' to compile many of my C programs.
>       Because OC & C are so close, they easily link and share data types,
> and memory pointers.
>
> OpenCobol combined with C is the best of both worlds:
>       Cobol for processing business transactions.
>       C for systems programming, threads, sockets, sigs, and events.
>
> I hear that one day soon we'll have OpenCobol 2.0, with function-id.
>       Not sure how this will work, or look.
>       I hope 'function-id' will allow local scope, like "local storage"?
>       Could be your path to classes and inheritance.
>
> --
> mike.