Path: utzoo!attcan!uunet!husc6!uwvax!tank!nic.MR.NET!shamash!nis!ems!pwcs!elric!hblask From: hblask@elric.Sp.Unisys.COM (Henry E. Blaskowski) Newsgroups: comp.lang.ada Subject: Re: Ada on comp.lang.c++ Summary: ada bashing response (long) Keywords: OO design, bashing Message-ID: <742@elric.Sp.Unisys.COM> Date: 22 Nov 88 21:02:00 GMT References: <6474@june.cs.washington.edu> Organization: Unisys Inc., Eagan, MN, 55121, USA Lines: 123 > From: Ted Holden, HTE > > >>you'd > >>die of old age WAITING for anything serious to get as far as a core dump in > >>Ada. ....... > >and I agree, unless you turn run-time checking off -- it's a FEATURE, not a > >bug! (Wouldn't you rather die of old age before seeing another core dump?) > To me, at least, it is inconceivable that anyone who has done much > serious programming could prefer Ada to C or C++. The last two projects I have been on have been very similar -- tactical displays for military applications. The major difference was the first was in C, the second in Ada. Therefore I feel qualified to respond to the claims of Ted Holden. Do I prefer Ada to C? It depends on what I am trying to do. > I have watched a 30 line Ada program take 27 minutes to compile on a > I am aware of at least one major > project whose managers simply refused to deal with Ada, successfully > convincing top brass that there would be a two year differential in the > time needed to complete the project with versus without Ada. I am aware Yes, Ada takes longer to compile. Of course compile time checking takes some amount of time. But how long do you spend tracking down type errors in your C programs? Usually more than the incremental compile time. Well, ok, you PERSONALLY don't make such errors, but what about the yo-yo next to you...? And yes, some managers are afraid to try Ada, but some are afraid to leave FORTRAN.. I bet some would use Basic if they could find the people to program in it. That says nothing about the language. > The idea [behind C] seems to have been: > > "Lets take a hard look at this little PDP7 and design a > language which is one-to-one with its logical operation > ... so that we end up with a kind of high- > structured, low-level language, a thinking-man's assembler. > > Ada appears to have been designed > as a physical embodiment of state-of-the-art principles of "software- > engineering", whatever that's supposed to mean, > ...with any considerations > of real-world computers being regarded, at least initially, as unimportant. Oh, I see, you mean real world *UNIX* computers. Sorry, but the bare chips which many of us work with don't have Unix operating systems. But this does bring up an interesting point. Unix is like assembly, only easier. How big of a project would you like to write in an assembly-like language? > The fact that, with most if not all Ada compilers, "hello > world" seems to take up irrational amounts of space, often as much as > 300K bytes, adds to this suspicion. But this doesn't increase linearly with the size of the program, like in C. The overhead is the same for small and large programs, so there is a break even point. How many weapons systems are less than 10 lines. And there is no reason the executable has to be much bigger than for a C program, which is what real systems care about. > ...using C language, he might have written Cobol-callable > routines incrementally. There is > no real way to call an operating system from a Cobol program. Ada can't help COBOL's problems. If the COBOL program had been written properly, there is no reason that using Ada, COBOL-callable routines can't be written incrementally. I've called C from Ada and vice versa. It's no big deal. > First, the programming style being promulgated by DoD for > Ada is anti-conducive to the stated goal of readability; > The verbiage hides the logic. When every > variable name looks like: > > "NUMBER_OF_CROWS_SALLY_ANNS_GRANDMOTHER_SHOT_WITH_HER_12_GAUGE_- > LAST_TUESDAY", First of all, Ada can have short names, but part of the goal is readability. Having worked with both, and using both styles, I MUCH prefer being able to read a statement and know what it means, especially when reading someone else's code, as frequently happens in the Real World. > Second, DoD is often insisting on portability via Ada rather > than portability via UNIX, POSIX calls etc. Again, not everyone has Unix on their newly invented chips, and probably don't have the time to write their own version for their specific hardware. > The better class of programmers coming out of the > schools will be used to the 2 second compiles of Turbo C and > Turbo Pascal. Offer them jobs involving Ada, and most if not all > of them are probably going to give you the finger I disagree. A lot of people are learning Ada in school, and will actually like it. Some people like C, some like Assembly, some like Ada. Isn't America great? > I figure to make a great deal of money teaching people > C language (and possibly C++). C is intuitively obvious, you don't need to TEACH it. :-) > You'd better believe, the Russians program in C. Hmmmmm.. > The thing I like best about C++ is the feature nobody says much about: > that it has all of the potential to serve as an intelligent replacement > for Ada Well, maybe if it got standardized, and easier to debug. The theory behind Ada is to do all the hard work up front, letting the compiler do the work. This is not without a price -- longer compile times, greater use of resources, etc. The real question is whether all the hassle is worth it. Having seen both sides, I have to say that for large projects with many programmers, the answer is yes. An individual programmer, who doesn't make mistakes, and promises to stay around and debug for the life of the project should use C. A person (or team) writing a small program ( <5000 lines, should use C. A person writing for a Unix based machine should use C. Defense related projects usually don't fit the C categories. Each language has it's place, and I don't think one will replace the other any time soon. h blaskowski I speak for myself, not my company.