Re: Perform Thru/Go to vs. Perform - Compile Speed

• Previous message: James J. Gavan: "Re: Examples on the USE statement"
• In reply to: docdwarf_at_panix.com: "Re: Perform Thru/Go to vs. Perform - Compile Speed"
• Next in thread: docdwarf_at_panix.com: "Re: Perform Thru/Go to vs. Perform - Compile Speed"
• Reply: docdwarf_at_panix.com: "Re: Perform Thru/Go to vs. Perform - Compile Speed"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 12 May 2004 12:15:41 -0700

I wrote:

> >Both the Unisys MCP/AS COBOL compilers are regularly called upon to
compile
> >monolithic programs in the range of half a million source lines and more,
> >and customers with such large programs must sometimes do what is
necessary
> >to recompile them after seemingly minor changes if they are to remain
> >monolithic.

Docdwarf replied:

> 'Our system was designed, decades ago, to use Phillip's-head screws. Over
> the years these have been changed to hex-head screws... so every time we
> open a toolbox and find a Phillip-shead screwdriver we get out a
> blowtorch, a four-pound sledgehammer and a special form we made; we heat
> the screwdriver-tip until it's red-hot and then use the sledgehammer to
> pound it into the form until the tip is re-shaped into a hex-head.'
...
> When it is time for system redesign it is time for system redesign... to
> quote Jefferson, 'We might as well require a man to wear still the coat
> which fitted him when a boy as civilized society to remain ever under the
> regimen of their barbarous ancestors.'

As it happens, later versions of the application-development product that is
the most frequent offender in this area no longer generate such huge
programs, but for those users that are comfortable with the existing
product, they see need neither to regenerate their applications nor rewrite
the programs they generate. Your opinion of how much money they need to
spend Right Now to fix what you regard as a critical problem might well
differ from theirs, and it's their money!

> 'The results can't be trusted, no... but we get them so quickly!'

I don't disagree. If the customer has always gotten the right answer, it is
reasonable for him to complain if it suddenly takes twice (or three times or
ten times) the processor resources it once did to produce the same answer
after recompiling a program. The priorities you as an outside observer
might mandate for the compiler developers might not match the priorities
that actual customers of the product might request!

> ... and besides... all ya gotta do is take out the blowtorch, heat the
> screwdriver-tip until it glows read and then use the sledgehammer to pound
> it into the form...

I went back and checked, and that's not it -- in fact, the edge cases in
question are ones in which the programmer is already attempting to use a
screwdriver as a sledgehammer, and the documentation clearly suggests "Don't
DO that!". The constructs in question work just fine when they are used in
any manner that can be considered "reasonable". But I have learned from
painful experience that "nobody in his right mind would dream of coding such
a thing" is irrelevant when it comes to what a compiler encounters.

For example, I can't imagine using INSPECT ... REPLACING on a *signed
numeric* item as having any positive impact -- it looks to me like it's a
guarantee of data corruption, and at best is an example of an attempt to use
a welder's torch to dig a hole. However, the standard specifies the
behavior in this area, and we actually had a bug fix a while back to ensure
that the statement now corrupts the numeric item in exactly the way the
standard says it should!

> >For some years I seriously considered hanging an effigy doll over the
> >entrance to my cubicle anytime I was attempting to find and correct a bug
> >introduced by this person's logic, not an infrequent occurence.
>
> '... not an infrequent occurence' seems to contradict 'rejected on
> cost/benefit/risk grounds'... but my ability to see such appearances might
> be why I don't get to make budget decisions.

No, I think you misunderstood. Most of the areas touched by this particular
author were not only buggy but philosophically incorrect in context, and
have long since been rewritten to eliminate both the manifestation (the
incorrect behavior) and the cause (the wrong-headed approach to the
problem).

The three remaining areas were restructured to improve clarity (without
actually revising the logic flow) eleven years ago, and there have only been
three problems reported in these areas since that time, the last one over
three years ago, all corrected. Despite the code cleanup, when bugs do
surface in these areas they can still be time-consuming to correct, and the
corrections often involve disabling some sort of optimization.

There is no contradiction; the bugs being mentioned were "not an infrequent
occurrence" *until* the logic was redesigned and rewritten (many years ago)
to correct the underlying incorrect assumptions. The bugs are gone because
the code that contained them is gone. There may or may not be bugs in the
*new* code, but they can't be laid at the feet of the author of the *old*
code.

The "risk" in this equation is the risk to current users of the affected
code that rewriting it might entail, and the likelihood that we would spend
more time correcting problems in the new code than we would have spent had
we left it alone, with its current (and documented) restrictions. If
nobody is complaining about its current behavior -- including the documented
restictions -- it's difficult to support a rewrite just on accounta it looks
yucky. If it works, don't fix it.

    -Chuck Stevens

• Previous message: James J. Gavan: "Re: Examples on the USE statement"
• In reply to: docdwarf_at_panix.com: "Re: Perform Thru/Go to vs. Perform - Compile Speed"
• Next in thread: docdwarf_at_panix.com: "Re: Perform Thru/Go to vs. Perform - Compile Speed"
• Reply: docdwarf_at_panix.com: "Re: Perform Thru/Go to vs. Perform - Compile Speed"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]