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

"Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message 
news:13tbq3hb852cjc9@[EMAIL PROTECTED]
>
> "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote in message
> news:63jqf7F27lussU1@[EMAIL PROTECTED]
>
> [snip]
>
>> 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.
>
> Just a couple of notes from an "optimistic observer". <g>

Other viewpoints always welcomed by me... :-)
>
> "COBOL (COmmon Business Oriented Language) is the
> programming language most widely used for commercial
> and administrative data processing." -- Micro Focus LRM,
> probably from the COBOL 85 standard.

Well, as it is the core of their business, they WOULD say that, wouldn't 
they? :-)

I don't believe it is even true today, but I can't prove it so won't argue

it.

>
> The most common paradigm for "commercial and
> administrative data processing"  is "clerks performing
> procedures on or with data". COBOL came into existence as
> a domain-specific language for impementing that paradigm.

Not exactly as I recall... and I was there :-)

COBOL's major attraction was that it offered an "easily maintainable, 
platform independent" approach to "data processing".  It is true that  it 
was about "performing procedures on or with data" but it also offered 
freedom from being locked in to a specific vendor (at least, that was a 
major perceived benefit; in practice, it was not so easy to switch 
vendors...) People were more excited by COBOL at a technical level than at
a 
functional level.

And, in those days, the concept of online interaction was not a 
consideration. All processing was deferred Batch processing. There weren't

even random access devices; data was stored and processed sequentially on 
tapes. These were the roots of COBOL. We have come a long way since. True,

when inteeractive devices became available, COBOL was enhanced to 
accommodate them, but the strength of the language was, and is, sequential

batch processing.

It is not COBOL's "fault" that it is not so good at interactive
processing. 
For years it was "the only game in town". Then came new approaches to 
programming and processing. The Object paradigm arrived and, again, COBOL 
was enhanced to accommodate it. A fantastic feat of software engineering, 
but wasted because of the limited vision of the COBOL community who 
perceived it as just a fa****on statement, unnecessary, and really just 
"modular programming, re-invented". The reality was that entrenched COBOL 
systems were doing most of the backbone processing and this led to a smug 
attitude on the part of COBOL practitioners who couldn't see COBOL being 
replaced any time soon... They had not factored the global effect and
power 
of the Internet into their calculations... Within a decade, thousands of 
COBOL programmers were jobless, and COBOL fell from being the No. 1 most 
popular language for developing commercial computer systems,  to being 
outside the top 12 programming languages, according to a number of 
independent surveys.
(http://www.scriptol.org/choose.php
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://www.devtopics.com/most-popular-programming-languages/)

The rest of the world, not having been indoctrinated into the procedural 
paradigm, rushed to embrace the non-procedural paradigm and it was found 
ideal for distributed, encapsulated processing. New languages, designed 
specifically for building Object Oriented systems emerged. They weren't 
"self  documenting" and "easily maintainable" in the sense that COBOL was,

and neither did they need to be. They were far more powerful and required 
less coding, and components built with them could be easily re-used. If 
something didn't work it didn't need to be "maintained", it could simply
be 
discarded and rebuilt, quickly and easily. By the 21st century, visual
tools 
capable of generating these objects were available, and today they are 
increasing in power exponentially, while COBOL is still tied to line by
line 
coding and green screen editing.

COBOL, as a language, was simply overtaken by events.

> Regardless of the implementation paradigm (procedural, OO,
> functional, etc.) the result will neccesarily reflect the underlying
> procedural basis for the required data processing. I suspect
> that a great deal of programming with OOPLs is procedural
> programming; but incorrectly claimed to be OO.

Maybe, but that is an academic argument. It doesn't matter what you call
it, 
the fact is that the new languages can be written quicker, re-written 
quicker, require much less code, and have facilities that COBOL simply 
doesn't. Whether they are doing procedural processing under the guise of
OO 
or not is immaterial; they can be generated to do it quicker than a good 
COBOL programmer can code the thousands of lines it takes.

I have been astounded at the encapsulated functionality in languages like 
C#, that simply isn't available in COBOL. It doesn't even matter what the 
paradigm is, it is quicker to point and click in Visual Studio, than it is

to write hundreds of lines of COBOL in ISPF. End of story.

>
> The expanding role for COBOL comes from the addition of
> general-purpose programming language features in 2002;
> features that complement the domain-specific features. Once
> the general-purpose features become widely available and
> discussed, more "multilingual" programmers can become
> comfortable with "I can do that in COBOL".

I understand what you're saying, Rick, but I contend that they won't. I
know 
from my own experience (somewhat like being dragged kicking and screaming 
into Java and C#) that the desire to go back to COBOL diminishes with the 
increasing understanding and facility in OO languages. Yes, I COULD
develop 
web applications in OO COBOL, yes, I COULD write OO COBOL components, but
I 
won't and don't. (I did for many years and felt like a "voice in the 
wilderness" receiving scorn and vitriol from most of the COBOL community 
when I suggested that OO might be im****tant for COBOL,  and a total lack
of 
sup****t from COBOL vendors when problems arose. Nowadays when I have a 
problem, I don't need or want to go to MicroSoft; there are around 60 
million people writing C#... I can get a GOOGLEd solution in minutes.
Also, 
the demonstrated attitude of the C# community is a helpful and positive
one 
in the C# forums I have used...) I just don't believe that once 
"multilingual" programmers go away from COBOL, they will need or want to
go 
back to it.

The "new" features in COBOL, even if they could be implemented, are not 
going to make any difference.

I respect MicroFocus for taking a hand in the standards debacle and I 
honestly wish them well. Whether they are driven by commercial necessity
or 
a genuine desire to improve COBOL, what they are doing is commendable.

Unfortunately, I believe it is too late.

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