[comp.software-eng] COBOL as a Programming Language

warren@jove.cs.pdx.edu (Warren Harrison) (05/03/89)

To: N43WF801@NCSUVM.BITNET
Subject: Re: Info. on Marketing SW Abroad?
Newsgroups: comp.sys.ibm.pc,comp.sys.atari.st
In-Reply-To: <667N43WF801@NCSUVM>
References: <4186@druhi.ATT.COM>
Organization: Dept. of Computer Science, Portland State University; Portland OR
Cc: 
Bcc: 


Warren Harrison                CSNET: warren@pdx.edu
Department of Computer Science UUCP:  {ucbvax,decvax}!tektronix!psu-cs!warren
Portland State University      Internet: warren%pdx.edu@relay.cs.net
Portland, OR 97207-0751

warren@jove.cs.pdx.edu (Warren Harrison) (05/03/89)

The discussion regarding COBOL has been quite interesting.  It seems
quite obvious however that the majority of people flaming COBOL don't
have much experience with it. 

If written correctly, COBOL is perhaps the most modular language
in use.  This is not at first obvious because few people ever use
subprograms in their college COBOL courses, and this appears to be
limit of most of the posters' exposure to COBOL.  In fact, COBOL
has NO global variables.  The only way in or out of a COBOL
subprogram is via the parameter list, which by default is passed
by address, but it can be forced to pass by value if desired.

I have successfully developed and taught a course on data abstraction
This can be inefficient, but it gives a great motivation for
students to address memory allocation issues [no new(xyz) ...
you're responsible for the free list or garbage collection yourself].
Data abstraction was much easier in COBOL than in Pascal since you
really could ensure the internals of the operation abstractions were
unavailable to the user.  Because of this, you didn't have any
"global linked lists" floating around that the programmer is tempted
to access outside the "pop" and "push" routines.

Unfortunately, the potential is usually not realized since most
CS COBOL courses are taught by either (1) people who know COBOL,
but have no formal CS training - eg, the adjunct instructor from
the local dog food plant or (2) CS faculty who know barely more
about COBOL than what is in the first 10 chapters of a sophomore
lvele text book.

Here are some of the good points of COBOL, that few other languages
have ... as far as I know, no other language has them all:

packed decimal number representation, built-in report writer,
built in (via the OS access methods that is) indexed sequential
file system, built in binary search and sorting commands, exception
flagging and handling, built-in string handling (eg, STRING/UNSTRING),
(REPLACE USING), pseudocode-like syntax (?).


Bad points:

Wordiness, poor control stuctures (fixed in COBOL 8x), no dynamic
RAM memory.


I may have missed some of each.  Note that my fondness for built-in
operations such as indexed files, string/unstring, etc. is because
I don't like surprises, and everytime I use someone's super duper
B-tree library, they seem to  want to change the calling conventions.


If you want to flame COBOL, please spend some time looking over the
language first.  It's potential is great.  It's too bad no one
is making use of it.

Warren

Warren Harrison                CSNET: warren@pdx.edu
Department of Computer Science UUCP:  {ucbvax,decvax}!tektronix!psu-cs!warren
Portland State University      Internet: warren%pdx.edu@relay.cs.net
Portland, OR 97207-0751

twb@cbnewsh.ATT.COM (thomas.w.beattie) (05/03/89)

In article <1120@psueea.UUCP> warren@jove.cs.pdx.edu (Warren Harrison) writes:
>To: N43WF801@NCSUVM.BITNET
>Subject: Re: Info. on Marketing SW Abroad?
>Newsgroups: comp.sys.ibm.pc,comp.sys.atari.st
>In-Reply-To: <667N43WF801@NCSUVM>
>References: <4186@druhi.ATT.COM>
>Organization: Dept. of Computer Science, Portland State University; Portland OR
>Cc: 
>Bcc: 

This errant posting reminded me of the following quotation:

     "The use of COBOL cripples the mind;
     its teaching should, therefore,
     be regarded as a criminal offence."
                       -E. W. Dijkstra (1982)

---
Tom Beattie
att!hoqaa!twb
t.w.beattie@att.com

len@synthesis.Synthesis.COM (Len Lattanzi) (05/04/89)

In article <1121@psueea.UUCP> warren@jove.cs.pdx.edu (Warren Harrison) writes:
:
:The discussion regarding COBOL has been quite interesting.  It seems
:quite obvious however that the majority of people flaming COBOL don't
:have much experience with it. 
:
:If written correctly, COBOL is perhaps the most modular language
:in use.  This is not at first obvious because few people ever use
:subprograms in their college COBOL courses, and this appears to be
:limit of most of the posters' exposure to COBOL.  In fact, COBOL
:has NO global variables.  The only way in or out of a COBOL
:subprogram is via the parameter list, which by default is passed
:by address, but it can be forced to pass by value if desired.

This is true of subprograms but the bread and butter of cobol is the
perform statement which allows 0 parameters.  The call statement is
more expensive than the perform and that alone would hamper any crusade
to write 'correct' COBOL programs. For those unfamiliar with cobol
ponder how many C programmers could be convinced to program using only
static globals and every procedure in a separate file? 

:
:I have successfully developed and taught a course on data abstraction
:This can be inefficient, but it gives a great motivation for
:students to address memory allocation issues [no new(xyz) ...
:you're responsible for the free list or garbage collection yourself].

It's very hard to concentrate on data abstraction issues if you're busy
chopping up global memory for heap usage. COBOL is not a systems programming
language.

:Data abstraction was much easier in COBOL than in Pascal since you
:really could ensure the internals of the operation abstractions were
:unavailable to the user.  Because of this, you didn't have any
:"global linked lists" floating around that the programmer is tempted
:to access outside the "pop" and "push" routines.
:
:Unfortunately, the potential is usually not realized since most
:CS COBOL courses are taught by either (1) people who know COBOL,
:but have no formal CS training - eg, the adjunct instructor from
:the local dog food plant or (2) CS faculty who know barely more
:about COBOL than what is in the first 10 chapters of a sophomore
:lvele text book.
:
:Here are some of the good points of COBOL, that few other languages
:have ... as far as I know, no other language has them all:
:
:packed decimal number representation, built-in report writer,
:built in (via the OS access methods that is) indexed sequential
:file system, built in binary search and sorting commands, exception
:flagging and handling, built-in string handling (eg, STRING/UNSTRING),
:(REPLACE USING), pseudocode-like syntax (?).

Very large installed base. Cobol and RPG have the lion's share in
terms of amount of code written.

:
:
:Bad points:
:
:Wordiness, poor control stuctures (fixed in COBOL 8x), no dynamic
:RAM memory.

No bit operations.
No Standard floating point types.
Packed decimal is limited to 36 digits
Paragraphs use of decimal point as implied end-if or end-perform can
lead to obscure bugs after code is modified. This is almost as bad
as Fortran's ability to compile "DO 10 I=1.10"

Except for my last point none of these Bad points prevent Cobol from
being an ideal 'COmmon Business Oriented Language' but neither does
Cobol's good points make it an ideal general purpose language.

:
:
:Warren Harrison                CSNET: warren@pdx.edu
:Department of Computer Science UUCP:  {ucbvax,decvax}!tektronix!psu-cs!warren
:Portland State University      Internet: warren%pdx.edu@relay.cs.net
:Portland, OR 97207-0751


-Len
 Len Lattanzi (len@Synthesis.com) <{ames,pyramid,decwrl}!mips!synthesis!len>
 Synthesis Software Solutions, Inc. 		The RISC Software Company
I would have put a disclaimer here but I already posted the article.