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

Pete Dashwood wrote:
"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 :-)


[snipped]

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.

Let me second or third or whatever that! 8-)

I discovered yesterday that list boxes in .NET store objects rather than just
strings (strings are objects). That means I can store an array of records
encapsulated as object instances in the list box. When an item in the displayed
list is selected, the code processing the click event has direct access to the
objects contents. No searching or sorting!

A PowerCOBOL list box ,at least as of version 5, only stores text, meaning that
code needs to be written to find the corresponding record in a table. Indicies
need to be managed in a synchronized fashion in the list box and the backing
table. Insertion, deletion, modification routines, etc. More code to write,
debug and support.

The really cool thing about storing objects in the list box is that the objects
do not have to all be of the same type. I'm not sure how often this will be useful
but I can see having a list box that presents the user with a hierarchy of choices
the choices relating to different types of things.


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."

Jeff






----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= - Total Privacy via Encryption =---
.

Relevant Pages

  • Re: Wang COBOL alive and well as Wang VS makes a comeback
    ... I fought to the last to keep COBOL at least peripherally in the ... will be the next language du jour... ... This contributes to the stability of programming efforts ... level of COBOL to another can be as big a deal as migrating across platforms ...
    (comp.lang.cobol)
  • 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)