Re: Next generation COBOL?
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx>
- Date: Mon, 28 Nov 2005 23:22:03 +1300
"david" <dskirk-dsk1@xxxxxxx> wrote in message
news:Xns971BC09AC46ABdskirkusanet@xxxxxxxxxxxxxxx
>
> 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?
>
I agree with most of what you wrote.
Here are MY thoughts...
Let it die with dignity. It will have served us well for 55 years by 2014,
albeit with diminishing relevance.
What really happened was that commercial computing had to get real and
become true computer programming. A language that had no basis in computer
science (it was invented before there WAS computer science) is not going to
meet the needs of today's world. The needs of the market place, the network,
the web, and even the desktop client server, will not be met by procedural
progamming in ONE language. When there was ONE machine, (and the demands on
it were mainly batch) that was possible; not today.
Tools are getting more powerful; people are getting more computer literate
and expecting more, and interfaces are getting more and more user friendly.
There's nothng "wrong" with COBOL, it's just that the pardigm it serves is
no longer relevant.
And people who are still promoting it as a way forward are just sad, and
completely out of touch with the real world.
Next generation COBOL? You might as well discuss next generation Sanskrit
or Latin.
For the past 15 years, it has become harder and harder to recommend
corporate IT services to base themselves on COBOL. Today it is impossible.
Even a dyed-in-the-wool COBOL lover like me won't do it. (I simply can't; it
would be ludicrous and I'd just not be doing my job.)
Small development for home computing, batch programming, refactoring legacy
systems, are the only reasons I see for learning COBOL right now. You can't
even recommend it as a good learning language (like, for example, Pascal),
because the concepts it is based on are simply not relevant today.
Why would you write systems in a language that locks you into a file system
that no-one else can access?
If you're going to use RDBMS, why wouldn't you use triggers and stored
procedures, generated by drag and drop tools that never make mistakes and
generate code in minutes that would take days in COBOL?
Why would I maintain huge libraries of COBOL source and bet my company on
them, when I can use Object components for maximum re-use and not have to
maintain them? If I'm really paranoid I can maintain Java source which
averages around one third the volume and has class libraries COBOL can only
dream of.
Had the COBOL community embraced OO some years back, COBOL might have had a
chance. Had the standard not taken 17 years to deliver, had ANSI and J4 not
destroyed all credibility the language once had, COBOL might have had a
chance. But it is only speculation and I certainly don't hold any of the
aforementioned as primarily responsible for the "death of COBOL". (I did for
a while, but I'm over it now :-))
It's time is over. That's the Holy All of it.
Pete.
.
- References:
- Next generation COBOL?
- From: Steve Richfie1d
- Re: Next generation COBOL?
- From: david
- Next generation COBOL?
- Prev by Date: Re: Next generation COBOL?
- Next by Date: Re: Cobol books & experiences
- Previous by thread: Re: Next generation COBOL?
- Next by thread: TANDEM COBOL, TAL & Enscribe professional needed in UAE
- Index(es):
Relevant Pages
|
|
