Re: Infinite Loops and Explicit Exits

From: Robert Wagner (spamblocker-robert_at_wagner.net)
Date: 11/07/04 

Date: Sun, 07 Nov 2004 10:59:45 GMT

On 6 Nov 2004 14:22:31 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
>
>> >Of course that does stifle progression, but the company is there to
>> >run the business, not write books on style.
>>
>> I disagree. Style can be refined in an EVOLUTIONARY (not
>> revolutionary) way without deprecating what came before. In the world
>> of cinema, such progression is called 'auteur theory'.
>
>"""The auteur theory was, of course, not a theory of film at all, but
>a method of evaluation which enabled people knowledgeable about film,
>film history and particularly individual directors to show their
>knowledge and superiority over the uneducated masses who did not know
>what John Ford's cavalry trilogy was or the importance of cigarette
>lighting in the films of Howard Hawks."""

The author would ban knowledgeable people from discussons. 'Don't ask
him about programming. He knows too much. Ask the intern we hired
yesterday.'

In Cambodia, people like the author sent 'intellectuals' to the
countryside for re-education.

>While both programming and movies are evolutionary, the old ones are
>not updated as part of a routine. Though 'The Jazz Singer' had audio
>added and 'Casablanca' was colourised, these were not common practice,
>remakes are usually failures. If movie companies spent their time
>'updating' old movies then they would not have time to make new ones
>and would go broke.

Consider the Hawks movies Rio Bravo and El Dorado. They had the same
characters and story line. The second was truly a rewrite of the
first.

>In much the same way with Cobol systems. Cost is a factor, they can
>spend their time constantly revising old systems just to make them
>prettier with no added functionality or they can write new one to
>extend the function of IT into new areas.

The black-and-white fallacy, again. Why not both?
 
>> If change is gradual, the same themes appear in old and new code.
>> There isn't a scism or fracture.
>
>Only if the systems are continually worked on for other reasons. In
>many cases systems may continue to be used for many years without any
>need for change. You seem to suggest that they should be changed for
>no other reason than to change the code. This, of course, also
>introduces risk. Unnecessary risk.

I advocate rewrite as a by-product of required maintenance. At the
supermarket company I cited, nearly all programs were modified within
a year. If there had been programs, or better whole systems, that were
untouched, I would have left them alone. Other places I managed had
untouched systems.

>> Typedef is available on Micro Focus and Fujitsu.
>
>Yes, how many mainframes run the PC compilers that support this ?

One can do the same with copybooks. It jost doesn't look as nice.

>> >Decisions and actions must always be made in different places, it
>> >can't all be in one line of code.
>
>> IF condition
>> action
>> END-IF
>
>You are implying that this cannot be:
>
> IF condition
> PERFORM action
> END-IF
>or
> IF condition
> CALL action
> END-IF

I'd rather CALL action unconditionally and let it make the decision.
That way, the 'business rules' are complete within a single program.