Re: Regarding EVALUATE TRUE

On Aug 17, 9:32 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
<klsha...@xxxxxxx> wrote in message

Hmmmmm... I think I Reply'd To Author yesterday, so the post did not
go "public"; I will attempt to repeat the substance for the benefit,
if you will, of all :-)

I was a little disappointed that, in response to your request, and having
taken the (admittedly short, and for amusement only) time to apply Boolean
simplification to:
<< difficult-to-understand code snipped >>
and obtained...
<< easier-to-understand code snipped >>
... you then chose to ignore this result completely and snipped it from your
response.

I am sorry to disappoint you. The original post of the condensed
version suffered from the same kind of defect as my Working-Storage
entry earlier, some kind of word wraparound and extra CR/LF's. This
made it difficult to read. Now that you have presented a well-
formatted version, I'll spend time on it...

I think this is pretty amazing. Especially when you think it was postulated
by two people who lived more than 100 years before the first electronic
computer was ever assembled.

Yes, sometimes simple tools are powerful.

Given that you claimed in an earlier post to be "cleaning up" the mess, I
would have thought this would be of some relevance.

Yes, it is relevant.


Instead, it seems you were distracted by the shiny bauble of a coding
technique you hadn't seen before :-)

Well, I picked the "low hanging fruit" first from your help. The part
about how the "flag" wasn't really a flag was significant, it was
easier, it helped, and it was consistent with the effort of
understanding the outer EVALUATE first.

Perhaps optimization of convoluted code might be on the agenda some time in
the future?

Yes, perhaps it might be. After sufficient understanding is reached.
Please let me explain. Let's review some context of what I said -

"And under what circumstances is the WHEN OTHER satisfied?
Will Mr. Dashwood please step forward to apply his De Morgan's
Laws? :-)"

Some of the defects are manifesting when this code segment doese
program does the "drop through", i.e., executes the "do nothing" WHEN
OTHER ... CONTINUE in the original, or simply "executes nothing
gracefully", as in your amended version. This is what I had in mind
when I also said earler, "It is left as an exercise for all the
Students reading this forum to determine the conditions under which
the WHEN OTHER is executed :-)."

Mr. Dashwood, I do believe that it will be easier for me to obtain
this answer by negating the AND's in your condensed version than it
would be for me to operate on the original EVALUATE. GThis is helpful
to me.

The problem here is that the program is sometimes (improperly)
dropping through, doing nothing, and not doing something that it
should. This is equivalent to "all the other decision criteria" not
being entirely correct. The spec doesn't say (there isn't any), and
the users can't tell me what those conditions are. We are definitely
pulling ourselves up by our bootstraps here.


On the other hand, I think what I learned is yet another way that a
programmer "can be too clever for his own good", or more accurately, a
programmer "can be too clever for the good of the maintainers that
follow...".

So much for style.

Now, how about a programmer actually cleaning up bad code? Your thoughts on
a postage stamp, by return, please :-)


I do not understand your comments, or why you would write them.


<snip>

The result would be less lines of code (in keeping
with your preference for parsimony, Mr. Dashwood), and a more direct
approach (in keeping with my preference for understandability over
cleverness.)

I have found in my (admittedly still ongoing) experience that parsimony
often helps understandability.


Yes, parsimony helps me too. Thoroughness, completeness, and
exhaustive coverage helps me more.

Thanks for taking time to help, Mr. Dashwood... I appreciate it.

Ken

.

Relevant Pages

  • Re: Regarding EVALUATE TRUE
    ... where I built the Boolean truth table and simplification. ... understanding the outer EVALUATE first. ... Will Mr. Dashwood please step forward to apply his De Morgan's ... programmer "can be too clever for his own good", or more accurately, a ...
    (comp.lang.cobol)
  • Re: Coming soon: Turbo COBOL from Micro Focus :-)
    ... I'm not sure what are being called 'overall costs' here, Mr Dashwood... ... employment as a COBOL Programmer is a lack of current IBM Experience. ... any PL/SQL jobs in your background' and turned down. ...
    (comp.lang.cobol)
  • Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
    ... Pete Dashwood wrote: ... The one I remember - and use - is 'six months from now nobody is going to ... remember if a milestone was hit or missed, they're going to know if they ... and your programmer presents irrefutable evidence that demonstrates it ...
    (comp.lang.cobol)
  • Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
    ... Pete Dashwood wrote: ... programmers is saying the quality of the code is shit and the milestone ... and your programmer presents irrefutable evidence that demonstrates ... implement Utterly Crap Code or let the milestone ...
    (comp.lang.cobol)
  • Re: Conversion of data & associated logic from ISAM to RDB
    ... 'Helpful', Mr Dashwood, might be in the mind of the beholder... ... programmer, and a patently stupid Project Manager, neither of whom have any ... Klaatu: I'm impatient with stupidity. ...
    (comp.lang.cobol)