Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!oliveb!pyramid!prls!philabs!ttidca!hollombe From: hollombe@ttidca.TTI.COM (The Polymath) Newsgroups: comp.software-eng Subject: Re: Computer langauges and software lifecycle - references request Message-ID: <4340@ttidca.TTI.COM> Date: 29 Apr 89 01:50:22 GMT References: <570@umiami.miami.edu> Reply-To: hollombe@ttidcb.tti.com (The Polymath) Organization: The Cat Factory Lines: 63 In article <570@umiami.miami.edu> slores@umiami.miami.edu (Stanislaw L. Olejniczak) writes: }... A person (a }professional programmer) was claiming that COBOL is probably the very best }langauge for software writing _in general_ (i.e., for applications not }specifically requiring facilities of special purpose langauges) because it }can do everything C or Pascal or FORTRAN can, ... This is true only in the broadest possible sense: All four languages can be made to get the job done. When you get down to _how_ the job is done, not to mention how efficiently, there are clear differences. One obvious example is dynamic allocation/deallocation of memory. Unless the language has changed considerably since last I had to deal with it, COBOL can't do this. In practice, the COBOL programmer has to size data structures to handle worst case conditions, if they know what those conditions are (or cross their fingers and hope, if they don't). Pascal and C programmers can dynamically allocate structures as needed, and release them when no longer needed, making for more efficient memory use and more compact object code. }... and in addition it is so }widely used and so well standarized, applications are generally }transportable from machine to machine with no modifications. ... Not necessarily so, in my experience. For example, one of my first COBOL projects was done on an HP-3000 using their COBOL-3000 language. At least one of its commands worked in a manner directly opposite to what was described in the ANSI standard. (That was 10 years ago, and I don't remember which one, only the outrage when I found the bug that bit me). I once even stumbled across a bug in an IBM COBOL compiler (is nothing sacred? (-:{ ). SDC was quite grumpy about applying the necessary patch. }... The sense }of the argument was that COBOL was the most "useable" language, which by }the virtue of its modularity, standarization, and wordiness made it the }easiest of the major langauges to create reliable, portable and modifiable }software. Most COBOL coding standards I've seen mandate use of the abbreviated forms of COBOL key words. So much for wordiness. I think COBOL is about as modular as BASIC and I've already commented on it's standardization. }These arguments did not sit well with me, and they still do not. I }believe COBOL is anything but that. However, I neither know COBOL well }enough to make a reasonable argument against it, nor do I know well }enough about the research about the benefits and drawbacks of various }languages as far as creation of reliable, portable, modifiable software }goes to support my belief with hard facts. IMHO, there are applications for which COBOL is an acceptable, if not ideal, language. These are mostly the things for which it was designed and intended. Reading massive amounts of records off tapes, pushing the data on them around a bit and writing them out again is the general idea. On the other hand, there are applications for which COBOL is a complete disaster to work with. For example, I once had to solve a point-polygon-inclusion problem in COBOL. It still gives me the shivers when I think of it. (-: -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe