Path: utzoo!utgpu!bnr-vpa!bnr-fos!bnr-public!schow
From: schow@bnr-public.uucp (Stanley Chow)
Newsgroups: comp.software-eng
Subject: Re: Computer langauges and software lifecycle - references request
Message-ID: <459@bnr-fos.UUCP>
Date: 2 May 89 00:08:24 GMT
References: <432@bnr-fos.UUCP> <2846@pegasus.ATT.COM>
Sender: news@bnr-fos.UUCP
Reply-To: schow@bnr-public.UUCP (Stanley Chow)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 56


I don't want to start a war about C, please forgive any remarks I made/make.


In article <2846@pegasus.ATT.COM> psrc@pegasus.ATT.COM (Paul S. R. Chisholm) writes:
>In article <432@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes:
>> Amazingly, it is possible to write good modular code in COBOL. It takes some
>> discipline but is certainly an order of magniture easier than doing so in C.
>
>Excuse me?  C has global variables, variables that can be local to a
>module (source file), and both temporary and long-lived variables local
>to functions (subroutines).  Cobol has global variables, and very
>limited subroutines (PERFORM).
>

I meant to say:

   it is easier to write modular code that is easily maintainable by people
   with minimal familiarity with the language.

In the commercial shops (for which COBOL is intended), getting good people is
very difficult. 


>> If I may preempt some objections to COBOL:
>      [...]
>>  - Not-block structured, no variable scoping.
>>     Again, true but irrelevent. Most shops have set up variable naming rules
>>     so that scoping is not needed.
>
>Rules the compiler can't check for you.  The lack of true local
>variables precludes recursion, unless you build your own stack.
>

Recursion, I don't consider to be a problem for COBOL. The problems usualy
don't need recursion. The odd time that recursion is needed, you can fake it.

Most COBOL programs that I have seen do not require many local variables. Anyway,
after your tenth clone of the print program, you are not likly to have much
trouble with the eleventh clone.

>>  - Poor choice of control structures.
>>     True, but in the right domain, the COBOL paradigm is very effective.
>
>I'd say the same thing for good 4GL's.  The intersection of their
>domains is pretty large, and the 4GL's are more concise.
>

I have not used any 4GL, so I can't say. But I imagine you are right on this.



Stanley Chow			..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
				bitnet: schow@BNR.CA.BITNET

Disclaimer: I speak for myself only. [And even then, it's only sometimes]