From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!hp-sdd!hplabs!hpcc01!hpcuhb!hpcllla!hpclisp!defaria@hpclapd.HP.COM From: defaria@hpclapd.HP.COM (Andy DeFaria) Newsgroups: comp.lang.ada Subject: Re: Re: What's really wrong with COBOL? Message-ID: <920022@hpclapd.HP.COM> Date: 29 Mar 90 18:31:13 GMT References: <8458@hubcap.clemson.edu> Organization: Hewlett-Packard Calif. Language Lab List-Id: >/ 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.