Re: COBOL ain't quite dead - yet !
- From: Richard <riplin@xxxxxxxxxxxx>
- Date: Fri, 31 Oct 2008 16:22:06 -0700 (PDT)
On Nov 1, 9:14 am, "tlmfru" <la...@xxxxxxx> wrote:
Richard <rip...@xxxxxxxxxxxx> wrote in message
news:18e8bb27-c836-4a0e-b611-04c111a41ee8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Oct 30, 10:12 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Howard Brazee" <how...@xxxxxxxxxx> wrote in message
news:747hg4965hgegcuojhe10um7ic1f5lnccg@xxxxxxxxxx
I have seen
PERFORM AAA THRU AAA-EXIT.
The problem with that it that breaking down the sections in a logicalAAA SECTION.
AAA-PARAGRAPH.
...
AAA-EXIT.
EXIT.
way is too much effort. Putting in a paragraph label is a lightweight
solution that makes you feel that the code is properly structured when
it is not. The style of having 3 labels and an EXIT for everything
makes it too laborious to properly compose, the style gets in the way
of expression.
Not if you're used to it. See your own comment below.
It is _still_ more work to add the additional lines, and make the
'obvious checks' on them than would be done without them.
Unreferenced paragraph labels (ie drop-through) causes additional time
for the next programmer who has to check whether this would cause a
logic change. For example if the PERFORM had been done in error to the
first paragraph name instead of the section name then the spurious
paragraph label would end the perform while a comment line would not.
Having the section and first paragraph labels 'costs' the possibility
of the wrong one being performed. Having an exit label 'costs' the
possibility of errors such as goto the wrong one, or having a goto
added when the paragraph was performed in error.
Some of those errors would still have the program perform perfectly
_until_, for example, a goto exit was added.
As the only validation for the correctness of the style is by visual
inspection of the whole program then it is not a style that I would
use.
The possibility of the errors you mention is obviated by testing, isn't it?
Surely you don't think that people using this style don't perform the
obvious checks?
I think that they _DO_ perform the necessary checks, and do the
necessary testing, in fact they _have_ to perform those checks and
tests if they want to ensure that the program is correctly following
the style and that the various pieces are in place and used correctly.
I am advocating that a different style does not require many of those
'obvious checks' to be done because the errors and omissions that the
checks are for cannot be made. The checks are usually done visually
while I would like the compiler tell me when I do something wrong.
I have seen programs where a goto in a section went to the wrong exit
paragraph but it was for an exception that was quite rare and probably
never got tested.
What mechanism do you have to find such errors ? Judson had a program
that read through the source and checked for correctness including
that labels had the name according to a defined structures and that
gotos were only to the exit within the section.
It may be that the checks you perform are 'obvious' to you, but may
not be so obvious to the next programmer.
As for the "correctness of the style" - I don't fully
understand what you mean by that; it strikes me as an esthetic matter rather
than a functional one
The 'style' is the one being discussed, or similar, where there is a
section, first paragraph, exit label and exit. Perhaps I should have
said "the correctness of the program in following the style".
- there are tools to format the listing, to flowchart
it, to determine execution paths, to show the usage of labels. A purely
visual inspection of any non-trivial program would be too laborious and
error-prone to trust.
And checking the formatted listing and the flowchart and the execution
path is done how ? Visually ??? Laboriously ?? Error prone ? Do you
think that merely printing a flowchart proves the program to be
correct.
What I am advocating is automated checking as far as possible. It is
simple to prove that there are no GO TOs, SECTION headers, EXIT
SECTION, NEXT SENTENCE or certain other structure. While the absence
of these doesn't prove that the program is correct it eliminates a
number of 'obvious checks' that would otherwise have to be made.
What is 'easy' is entirely what you are used to. When one writes code
in a particular style one knows exactly the idiom and thus makes no
(or fewer) mistakes. I have worked on code that is as you describe
that had many errors and bug-traps. It was obvious that some other
programmer had later worked on the code and didn't understand the
idiom, or didn't adhere to the style correctly.
So it wasn't the style that was to blame, was it? Just as you say, "What is
'easy' is entirely what you are used to.".
What I was saying is that many people claim that their style is
'easy', that the checks they do make are 'obvious', and that they do
not make mistakes with it, and they expect that others, including the
'next programmer' to find it just as easy and mistake free.
In fact the 'obvious checks' you refer to may well be obvious to you,
the question is: will the next programmer know that those checks are
'obvious' and do them ?
My opinion is that the only persons qualified to judge styles are the ones
that have worked with many.
Over the last 40 years of working with Cobol and several other
languages I have worked with many styles, including the one that Peter
uses.
Many times I have had to maintain or make
changes to programs written in styles that I didn't like, but by conforming
to that style I almost always did the job properly and learned something in
the process. I STILL don't like goto-less programming but I'm not about to
say that it shouldn't be used for that reason.
Cobol went beyond goto-less programming 20 years ago.
What other languages, modern ones, have you also used ?
I suggest that if you learned to use Java, C#, Python, Ruby or similar
you may find that you change your mind about how programs should be
written.
(My one unsuccessful maintenance experience was on a program that neither I
nor the previous SIX people that tried could understand how it worked at
all. I gave up and rewrote it).
I've done that too, including one where I designed the system and was
supposed to have all the programs written by the programmers. One
struggled with the program they were given for 3 weeks. When it was
required to be working at the end of the week I took it over, couldn't
understand what he had written (even though it was my spec), tossed it
away and wrote a working program overnight. It went live the next day.
That programmer never worked again on the same projects that I did.
.
- Follow-Ups:
- Re: COBOL ain't quite dead - yet !
- From: tlmfru
- Re: COBOL ain't quite dead - yet !
- From: tlmfru
- Re: COBOL ain't quite dead - yet !
- Next by Date: Re: COBOL ain't quite dead - yet !
- Next by thread: Re: COBOL ain't quite dead - yet !
- Index(es):
Relevant Pages
|
