Re: J4 - presentation/discussion on "Future of the COBOL Standard"

"William M. Klein" <wmklein@[EMAIL PROTECTED]
> wrote in message 
news:HAXAj.5290$FE.820@[EMAIL PROTECTED]
>I thought that some (many?) of those who watch CLC would be interested in
a 
>paper that was just put out on the J4 website.  The following are the 
>"foils" for a Micro Focus presentation scheduled for next Wednesday,
March 
>12.  If anyone reading this newsgroup has comments that they would like 
>included in the discussion, you probably could still send them to the J4 
>chair (before Tuesday) and ask that they be included in the discussion. 
>You can send such comments to:
>
>    bobkarlin <at> karlinskorner.com
>
> and you may want to CC one of the presenters and ask for your views to
be 
> included in the discussion.  If so, CC:
>
>    John.Billman <at> microfocus.com
>
> The presentation foils are:
>
>    08-0034 - Future of the COBOL Standard (Billman)
>
> available at:
>
>     http://www.cobolstandard.info/j4/files/08-0034.pdf
>
> -- 
> Bill Klein
> wmklein <at> ix.netcom.com

I won't be copying Bob Karlin, but here's what I think, anyway :-)

As COBOL is fundamental to MicroFocus' core business it is understandable 
they would want to try and rejuvenate or re-invent it.

I think their idea to rejuvenate the standard is not a bad one, but to 
expect COBOL to move into a world of objects and components, when there is

no user interest in the OO features of it, is simply myopic.

Line by line development and maintenance of code is non-viable as a
forward 
strategy, and the only place where there is likely to be a COBOL market 
for 
some time yet is in Legacy and re-factoring or re-wrapping Legacy so it
can 
run in modern environments like .NET/Mono.

Any new standard should be stressing support for building OO components in

COBOL. As there is no user demand for that, there is little point in doing

it.

Doing what there IS user demand for (pretty much "same old, same old"), 
while commendable on the part of MicroFocus, is expensive and ultimately 
pointless. COBOL users (for the most part...) are currently out of touch 
with IT reality. The people who are demanding features like XML support 
haven't realised that the world has already moved on and XML is almost 
obsolete. Sure let's cater for bigger numbers... (does it REALLY matter?) 
The demands of the (rapidly dwindling) COBOL community are really not
worth 
catering to in the hopes of future long term revenue generation.

It's like Mediaeval scribes demanding better quality parchment and goose 
feathers, while Gutenburg is building his printing press.

Despite the claim of billions of lines of existing code (dubious at best;
it 
has been eroded yearly for the last 5 years (at least...) at a rate of 
millions of lines every year, by replacement with packaged solutions, 
refactoring, and migration to Java and other solutions...), even the most 
optimistic observer cannot see an expanding future for COBOL as a
procedural 
paradigm based language in a world that is increasingly more visual and
more 
non-procedural.

If I were MicroFocus, I'd be doing some focusing on transport/migration 
mechanisms for COBOL, leveraging and re-factoring tools, and support for 
visually building COBOL components that can play nicely with other
languages 
on level playing fields, like .NET.

Pete.
-- 
"I used to write COBOL...now I can do anything."



>