COBOL, 4GL, C, etc.

> From: Jack Parker <jparker@hpbs3645.boi.hp.com> > Subject: Re: Boss thinks COBOL leading edge in.. > To: informix-list@rmy.emory.edu (Informix Users Net) > Date: Tue, 14 Feb 95 8:03:37 MST > [snip] > > The best arguement I've ever heard > for using COBOL, that I happen to agree with, is that it is self-documenting. > Yes so is 4GL, but in COBOL there is not as much danger of misinterpreting > what the author was trying to do. Its harder to get into trouble writing in > COBOL. > > As for slow coming up in 'c' and being 'trendy'. I agree that it is easier > to get into trouble with 'c'. This is because it much more free-form than > COBOL, you are virtually unrestricted in your capabilities. Consider the frequent "obfuscated C" contests, in which the intent is to make the source code for a working C program as UNclear as possible. In a way, there is something "wrong" with a language that allows this. Such a contest would be impossible in COBOL. > Such power takes > a great deal longer to master than does 'MOVE A TO B'. Some of the things > you can do in 'c' are just mind-boggling. I have also seen bad programmers use mind-boggling techniques when simple ones would suffice. Then they usually want me to help them debug the mess they made. > In COBOL you write 3000 line applications, sure you copy an old pgm and just > change the stuff you need. In 'c' you write 30 line modules that, if > written properly, you never change, you just use them as is, over and over > again. A 'c' program is generally just cobbling together previously written > modules. I have read (and based on my experience with both COBOL and C, I agree) that with C you build up libraries of lower level functions, and write new main programs, while with COBOL you use a standard skeleton program and write new lower level sections and paragraphs. Shucks, that's pretty much what you just said. [snip] > Do I NEED 'c'? Yes. There are times when I need a capability that just > doesn't exist in 4gl, or works better in 'c'. There are also times when > speed is essential. I just finished a 4gl program that processed 13MB of > data in 20 minutes - this on a fast box, granted the algorithm is not > the greatest. I am going to re-write it in 'c' and will be very surprised > if, using the same algorithm, I can't get the time down to under 60 seconds > for the same data. I would be somewhat surprised if you achieve this level of speed-up by switching from 4GL to C. Most database applications are I/O bound, not compute bound. Unless you are doing MASSIVE string manipulation (for example) on the data between reading it and rewriting it, your compute time will probably be small relative to your I/O and wait time. > The first time I tried a re-write of this nature was against a 47MB file. > It was also an early excursion into real-world Pascal for me. The app had > been written in BASIC or something and took about 90 minutes to process the > data. I kicked off the first version of the program, in which I was just > trying out the central logic, and it blew up immediately. Rats - there's > something wrong, I put in writeln statements to see what was going wrong > and discovered that the reason the program was blowing up was the I hadn't > handled the EOF condition properly. It was processing the entire 47MB in > under 2 seconds. The difference between compiled Pascal and interpreted Basic is not analogous to the difference between compiled C and (compiled) 4GL. Even with interpreted 4GL, you will not find the same order of magnitude type of difference. On at least three occasions, I have had the exact same 4GL source code run FASTER, though not by much, in interpreted 4GL than in compiled 4GL. I have not figured out exactly why this happened, but three times is no longer a one-time fluke, and it supports my statement that I/O time rather than compute time is normally the driving factor in database application run times. > Unfortunately I don't know 'c' well enough to include it on my resume, so I > don't use it for 'resume-building'. Go ahead, include it as a "secondary language". I've seen your code; C belongs on your resume. Especially in this day and age when some bull shippers put stuff on their resumes that they can't even spell correctly! > _____________________________________________________________________________ > Jack Parker - Hewlett Packard, BSMC Boise, Idaho, USA > jparker@hpbs3645.boi.hp.com > _____________________________________________________________________________ > Subtlety is the art of saying what you think and getting out of the way > before it is understood. Good quote, and subtle! Regards, Alan +---------------------------+-----------------------------------------------+ | R. Alan Popiel | Internet: alan@den.mmc.com | | Martin Marietta, SLS | Voice: 303-977-9998 | | P.O. Box 179, M/S 3810 | Standard disclaimers apply. Cutesy ones, too. | | Denver, CO 80201-0179 USA | Your mileage may vary. Void where prohibited. | +---------------------------+-----------------------------------------------+