COBOL, 4GL, C, etc.

Alan writes: } } 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. (I just have to play D.A. here - even though I agree with much that Alan says) Just because I can take a piece of wood and carve intricate shapes into it does not mean that wood in and of itself is a poor building mdeium. } } > 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. One of the things about 'c' which I found mind-boggling the first time I ran into it was the ability to load a pointer with the address of a function and then execute the pointer. A de-referencing technique which was a gold-mine for me at the time. } } > 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. In this particular case, the program is doing a lot of string manipulation, so I expect a good speed up. I'm also going to try asynchronous reads from disk so that the program just has to handle internal stuff. } } > 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. Your absolutely correct, poor example on my part. } } > 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! Sweet of you to say. I suspect that's because your 'c' skills are at least an order of magnitude better than mine (not too hard) and your trying to make yourself look better. :-). cheers j. _____________________________________________________________________________ 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. _____________________________________________________________________________ Any opinions expressed herein are my own and not those of my employers. _____________________________________________________________________________