Re: Next generation COBOL?

On 24 Nov 2005 david read the comp.lang.cobol post of Steve Richfie1d,
which stated...

> As a concept, the original COBOL (before they started tacking numbers
> onto it) was a thing of beauty - where with some skill you could
clearly
> state your methodology in grammatically correct English, that even an
> untrained secretary could read.
>
>
was this ever really true? i was actively involved with cobol from 1965
to 1995 or so... and wrote several books on the topic... but i was
surprised about 12 years ago when i picked up a popular cobol text from
those early years - mccracken, i think - and noticed how horrible the
code was... the code was written in paragraphs such as that untrained
secretary might write. IF-THEN-ELSE statements were embedded within the
paragraph. one of the early errors of cobol was the encouragement to
write grammatical english that non-technical people would understand.
that's fine for simple processing, such as a COMPUTE statement, but
structural statements are best left to pros. nested IF statements, for
example, are confusing to the general public, as is the concept of AND,
NOT, and OR.

cobol's problem was that it appeared simple, yet was not. the concept of
structured programming became popular in the mid '80's, but only after
years of quarrel. and even in the '90's, many cobol programmers refused
to accept that procedural code could be written without GO TO statements.

OO code has done a lot to improve the perception of cobol, but as i look
back, i question whether cobol should continue to exist. cobol carries
many sacks of rocks for which it doesn't deserve punishment. many posts
address limitations of earlier versions... and new changes. if we
eliminate the environment division (which was critical 40 years ago for
hardware dependencies) and the data division (which was necessary to
define vendor-dependencies on data formatting) and acknowledge that the
identification division's importance disappeared 20 years ago, that just
leaves the procedure division, which begs to be eliminated, being the
only division left. thoughts?


--
_____
david
.

Relevant Pages

  • Re: How proprietary is the "COBOL file system"
    ... the growth is not significant enough to impact the demise of COBOL. ... spiralling cost of procedural code. ... year) companies are finding that the costs of in-house development on the ... 2005 Mizuho, largest bank in Japan, loses 270,000 bank accounts, says they ...
    (comp.lang.cobol)
  • Re: How proprietary is the "COBOL file system"
    ... the growth is not significant enough to impact the demise of COBOL. ... spiralling cost of procedural code. ... year) companies are finding that the costs of in-house development on the ... 2005 Mizuho, largest bank in Japan, loses 270,000 bank accounts, says they were probably ...
    (comp.lang.cobol)
  • Re: Java compatibility issues (WAS: MF having issues?)
    ... within Procedural code there are a tremendous number of features ... For this task PL/I definitely better than Cobol ... it's not your language of choice then there is a learning curve. ...
    (comp.lang.cobol)
  • Re: OO past and future was Re: How proprietary is the "COBOL file system"
    ... It's pretty easy to check the "growth" and popularity of COBOL vs the ... to web programming, or even application programming that is component ... Modern packages use OO inasmuch as they use components which are OO based. ... spiralling cost of procedural code. ...
    (comp.lang.cobol)
  • Re: Prodcuing an output file only on Friday?
    ... move "value-integer" OF registry1 to frequency ... class MyClass { ... I don't know anything about what the standards say, i.e., COBOL 2002. ... data division. ...
    (comp.lang.cobol)