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



"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:13tbq3hb852cjc9@xxxxxxxxxxxxxxxxxxxxx

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:63jqf7F27lussU1@xxxxxxxxxxxxxxxxxxxxx

[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 fashion 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 important for COBOL, and a total lack of
support 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."



.

Relevant Pages

  • Re: 7E7 Flight Controls Electronics
    ... was just good thing that that localization was not too easy - it would ... Please don't confuse abstraction skills of typical COBOL programmer (that ... I pointed at the current programming "biblioware" for commercial data ... > language was because I learned all the workarounds. ...
    (comp.lang.ada)
  • Re: Structured Coding
    ... more visual, some are more conceptual, some are more language oriented. ... I had major problems struggling with OO COBOL when it was first released. ... programming language ever written; light hearted, witty, amusing, ... Later I had to run some courses in Java Web programming and ...
    (comp.lang.cobol)
  • Re: New Cobol compiler written in Cobol
    ... It didn't have a visible operating system. ... > If I were writing a Cobol compiler, I wouldn't look at today's market. ... > What will a programming language need to be successful in that world? ... They'll use a language they can understand at a glance. ...
    (comp.lang.cobol)
  • Re: Gartner on Assessing the Age of Software Languages and Tools
    ... It's doing some Romero-level twitching, ... We have a lot of customers with no mainframe COBOL at all, ... COBOL.NET does everything that any other .NET language does. ... And of course the whole *point* of the CLI/CLR is that it simplifies mixed-language programming, so it's trivial to use one .NET language for the bulk of an application, and drop into another if it is better suited for some particular aspect. ...
    (comp.lang.cobol)
  • Re: Java compatibility issues (WAS: MF having issues?)
    ... language it can do most of what C, C++, and Java can do. ... 2002 COBOL standard addresses that, but having a standard is a far ... Some flavours do have libraries. ... On the IBM mainframe we have Language Environment but it does ...
    (comp.lang.cobol)