Re: [open-cobol-list] On forum registration problems

[David Jackson]

On Sun, Aug 7, 2011 at 4:48 PM, John Culleton <address@hidden> wrote:

On Sunday, August 07, 2011 03:28:43 pm William M Klein wrote:

> I strongly recommend AGAINST supporting the *full* 2002 COBOL Standard. It

> has as required a NUMBER of things that are now OPTIONAL in the draft

> revision (which should become official in the next year or so).

>

>

>

> for example,

>

> VALIDATE

>

> Report Writer

>

> WRITE file-name (not record-name)

>

> ARITHMETIC is STANDARD (Standard-Decimal and Standard-binary are new in

> the revision)

>

> Locale support

>

> Multiple Inheritance and Parametric polymorphism

>

>

>

Sounds like common sense has taken over. Perhaps the standard makers actually talked to working COBOL programmers for a change.

One problem is that the professors who teach COBOL in school (if there are any left) and most COBOL text book writers are for the most part people who never worked as a COBOL programmers. They like OO, they like Java, they like C++. So they try to bend COBOL to make it fit their predilictions. For a while it seems that the COBOL standard writers were of the same ilk.

COBOL will never be like Ruby, or Scheme, or any similar language. It has a different mission. It deals with very large data bases and the decimal arithmetic of accounting systems. Order Entry, Inventory Control, General Ledger, Payroll, Shop Orders, Mailing Lists: these are the tasks that COBOL does better than any other language. And it should read like plain English. To the extent practible is should have the tools to make it self-documenting, including all the paragraphs of the Identification Division as an agreed-upon template.

(End rant, I have to get ready for church.)

--

John Culleton

"Death Wore Black" Police procedural: http://www.deathworeblack.com/

"Create Book Covers with Scribus"

http://booklocker.com/books/4055.html

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list

I will disagree with this, it should be a project goal to support COBOL 2002 as well as COBOL 85. Only some compilers may support COBOL 2002 at this time but we want to remain compatable with them and assure that there is compatability, and other compilers probably will implement support for it. 

OO features are well known to improve the design of programs. People are looking for these features, by adding them to COBOL no one is required to use them, but those who want them and look for this in the language will find them, this will increase COBOLs uptake. You may not like OO, i think thats your loss, but, COBOL is not a very popular language today and that is due to the perception it does not support higher level programming features such as OO which are needed by many massive software projects.

It is best to take a mechanism not policy design goal here and make functionality available and let the programmers decide whether they are appropriate for a specific project. We cannot anticipate if a certain feature will be useful for a programmer or make assumptions that it is not valuable for some unforeseen circumstances. 

I fully support COBOL 85 and traditional support for all COBOL features and traditional styles, as well it is crucial that OpenCOBOL also support a full set of modern features such as OO, for it to become more popular. COBOL is a fading language and I think these features will help revive it, adn these features are an addition to the current language, they do not require the existing language be changed at all. So its still COBOL, just more powerful and with more capability. 

Standards and features support is important. lets not limit the capabilities or compatability. 

https://lists.sourceforge.net/lists/listinfo/open-cobol-list