Re: Re: What's really wrong with COBOL?

[defaria@hpclapd.HP.COM (Andy DeFaria)]

>/ hpclapd:comp.lang.ada / alawrenc@sobeco.com (a.lawrence) / 10:21 pm  Mar 27, 1990 /

>You may dislike COBOL, but for large _business_ systems I wouldn't use
>any other language.  I can put multiple programmers to work on the same
>program (I have had as many as 10 work on the same program at the same
>time). The programmer who "tests/debugs" a module does not have to be the
>programmer who wrote it.  Without any code generation tools I can expect
>an average though put of approx. 100 line of code per man day, including
>design and testing time.  The code will be portable without any special
>hooks (i.e. conditional compilation lines) to any machine with a ANSI
>COBOL compiler.  My programmer's won't waste time chasing bugs cased
>by pointers being misused, writing special file access routines, or trying
>to write their "own" function for string manipulation.

I've  been a consultant  on HP3000's  running MPE were COBOL V/PLUS (screen
package) and   IMAGE (DBMS) are the norm    for 10 year   so  I  speak from
experience when I say I have seen the worst code and most of it  is written
in COBOL.  This is not to say that you  *have*  to write bad code in COBOL.
Indeed I have seen good code in COBOL too.  In keeping with the theory that
each language is a tool that has  value and can be  applied to a problem at
hand, COBOL is  also a  tool that  has value can  is useful.

What's wrong with COBOL is that it hasn't kept  pace.  In  the COBOL that I
used to use there was no  support for  floating point numbers, pointers and
bit fields.   These are simply limitations  of the language and they  cause
programmers problems  that  must be gotten  around.    By  saying that your
programmers "won't waste  time chasing bugs cased  (sic) by  pointers being
misused"  you are  also saying   that your programmers won't  use pointers.
Pointers  are  very  useful.    You're COBOL  compiler  uses  them but  you
programmers  can't.   So when they  are faced with  a problem that pointers
would easily and cleanly solve, they can't use them and  are forced to come
up with another,  often uglier and  slower,  solution.  Are you saying that
floating point numbers or bit fields are not  useful!  Well other languages
use these things and if you're interfacing to them you have problems.

Another thing  about COBOL that I  could never  understand is the  lack  of
understanding of  the  language itself by  the  people that  use  it.   For
example,  COBOL  programmers are inhertantly bad  at defining  dates.  I'll
often see 10-20 definitions for CURRENT-DATE and  tons of  useless  move of
data from a PIC 9 field to a PIC X field so that the programmer can  say IF
CURR_MM_X = "10" instead of IF CURR_MM_9 = 10.   To me this  is just a lack
of understanding  of the  language itself.  I'll eliminate the  extra dates
and use only 2 or 3 (MDY, YMD) and the program will work like a champ.

I also can't tell you how  many times  I have seen  terrible abuses of I/O.
Programmers who CLOSE AND RE-OPEN FILES JUST TO REWIND THEM! or OPEN a file
write a record  CLOSE the file  only to perform the OPEN-WRITE-CLOSE  again
and again for thousands of records only because they're too lazy to code it
to keep the file open.

Besides not  keeping  pace,  COBOL  seems to   get   all those MBA  degreed
"wanna-be" programmers  which gives COBOL a  bad rap and keeps  the  coding
sytle at a minimal.