Re: Boss thinks COBOL leading edge in..

> > Just my opinion.... In my short (6 years) in data processing I > have found that of all of the "high level languages" (COBOL, C, > PASCAL....) programming in COBOL tends to be the most productive > for the time spent developing. I have in the past year switched [chomp] > I have found that the reason that most developers want to abandon > "old" languages has more to do with trendiness and resume > building than any real need. > I agree that COBOL is far from dead and deserves to be kept that way. It has evolved over the years - you can even write to a terminal and stuff now! I think COBOL++ is just around the corner. 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. 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. 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. It is frequently difficult for top-down programmers to make the switch to this modular style. When they finaly figure it out and after building, buying, or borrowing a toolbox full of well-written modules, a 'c' programmer can be mondo efficient. If you write 3000 lines 'c' programs the odds are a) that you are doing it wrong b) that there are going to be all sorts of places that you have to watch out for things. 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. 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. Unfortunately I don't know 'c' well enough to include it on my resume, so I don't use it for 'resume-building'. my $.02 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. _____________________________________________________________________________