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=2.1 required=5.0 tests=BAYES_05,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo alt.cobol:127 comp.lang.ada:3542 comp.infosystems:84 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ncrlnk!usglnk!uspm650!steve From: steve@uspm650.Dayton.NCR.COM (Steve Bridges) Newsgroups: alt.cobol,comp.lang.ada,comp.infosystems Subject: Re: What's really wrong with COBOL? Message-ID: <913@uspm650.Dayton.NCR.COM> Date: 25 Mar 90 03:41:37 GMT References: <423@mck-csc.UUCP> <8468@hubcap.clemson.edu> <1990Mar24.154331.3328@world.std.com> Reply-To: steve@uspm650.Dayton.NCR.COM (Steve Bridges) Organization: NCR Corporation - USG Product Marketing, Dayton List-Id: In article <1990Mar24.154331.3328@world.std.com> madd@world.std.com (jim frost) writes: >billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) babbles: >> There is also multitasking -- the ability to express the idea of >> objects which do their work in parallel. >[...] >> it is necessary to implement it using what is known as "recursion". >> This is what happens when a procedure or function calls itself >[...] >> ...an "abstract data type" ... is a style by >> which one identifies and characterizes a real-world object through >> a description of the operations which can be done with that object, > >What is this, a review of a freshman course in CS? Have you resorted >to believing that all people who use cobol are "common folk, people of >the land (you know, morons)"? > >Assume, for a change, that we're all professionals here and don't need >trivial concepts described, especially inaccurately. Jim is right -- this does sound like a freshman CS course (a whole lot like a one I took). Let's face facts -- there is nothing inherently wrong with COBOL. A properly structured COBOL program CAN have a modular design, can do recursion (see the following code segment: PROCEDURE DIVISION. MAIN-PARA. MOVE "N" TO PARA-STOP. PERFORM PARA-A THRU PARA-A-EXIT. STOP RUN. PARA-A. do something here. PERFORM PARA-A THRU PARA-A-EXIT UNTIL PARA-STOP = "Y". PARA-E-EXIT. If you dissect that code, it is recursive. The initial call in the main paragraph will execute ONCE. The second perform within PARA-A will continue to perform PARA-A UNTIL THE EXIT CONDITION IS MET!. Granted, COBOL was designed a long time ago, but it is still a valid language, and possibly more portable than C. COBOL exists for all the operating systems I am familiar with (Unix, MS/PC-DOS, CP/M, MVS, VMS, VRX, ITX, IRX, IMOS.....). You can take that same COBOL code, re-compile it on the target machine, and IMHO, probably spend less time getting it to work than trying to take a C program with it's dependence on include files. Don't get me wrong, C is great for some things, but let's remember why COBOL was developed... for businesses. Not to write operating systems in, or word processing applications, or other similiar types of things where you have to get down and talk to the hardware at a lower level than COBOL (or FORTRAN) will allow. In our department, we use COBOL on a daily basis. Why? Because development time is quicker, debugging is easy, file I/O is quick, and it runs like a scalded cat. But, we also use 4 G/L type products like Informix and Progress. Why don't we use Pascal/C, or other object oriented type stuff? Because IT DOESN'T MEET OUR NEEDS. We need to analyze business information, not spend time worrying about abstract data types and whether our product can do recursion. Granted, if we were responsible for writing operation systems and the like, OO type languages would be the choice, but we don't. Bill - I guess what I am trying to say is don't condemn a language that people use until you look at what the problems they are trying to solve. -- Steve Bridges | NCR - USG Product Marketing and Support OLS Steve.Bridges@Dayton.NCR.COM | Phone:(513)-445-4182 622-4182 (Voice Plus) ..!ncrlnk!usglnk!uspm650!steve | AOPA #916233 ..!uunet!ncrlnk!usglnk!uspm650!steve| PP-ASEL, AMEL