Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!sei.cmu.edu!jjs From: jjs@sei.cmu.edu (Jeffrey Stewart) Newsgroups: comp.object Subject: Re: ada-c++ productivity Keywords: Looking for a few lazy men Message-ID: <23084@as0c.sei.cmu.edu> Date: 22 Mar 91 14:58:35 GMT References: <11966@pasteur.Berkeley.EDU> <1991Mar15.224626.27077@aero.org> <1991Mar16.000624.2513@leland.Stanford.EDU> <1991Mar16.205228.4268@grebyn.com> <1991Mar21.024445.8746@grebyn.com> Reply-To: jjs@sei.cmu.edu (Jeffrey Stewart) Organization: Software Engineering Institute, Pittsburgh, PA Lines: 57 Well heck, Ted. I didn't want to get into a language war, but since you started it... First, let me say that I've done projects in both C and Ada, and have been formally trained in both languages. Much has been made of C's concise syntax, that in fact this is a great attribute of the language. However, this conciseness has led to horribly complex semantics, which I feel is one of C's greatest drawbacks. Also, much of what was left out of C's capabilities was put back in as the "standard libraries". I'll say more about those later. A C culture has developed around the complex semantics ("anyone who doesn't know C shouldn't be programming in it"). In fact, rather than being used to judge the language (it probably shouldn't have these problems), knowledge of the complex semantics, and the required workarounds, is considered a prerequisite of being a competent C programmer. Ada, however, has a far more uniform set of semantics, which made learning the language a joy for me, because once I learned something, I found that I could apply it equally in many different areas, and it would always work the way I thought (i.e., no "side-effects"). Now on to the "standard libraries". Part of the size of the Ada syntax is that much of what are in the C libraries is built into the Ada language itself. We can argue about whether that was a valid design decision, but I think it was, given the design goal of portability, and the testing required to ensure that a compiler achieves that goal. (I'll talk about testing in a moment, too.) I wish my brother were on the net. He also knows both Ada and C, is forced to work in C, and wishes he could work in Ada. His Engineer's Degree (halfway between a Masters and a Doctorate) thesis required development of a plasma simulation, in C, to be ported from a VAX to a Cray and then to a PC. The horror stories about the, um, loose interpretation of whatever passes as a spec for the C language are too numerous to detail here. Some of those problems had to do with the syntax and semantics, but many more had to do with those "standard" libraries, which are anything but standard. My brother is now in the commercial world, and is tasked with porting a 300KLOC C application to "any platform he can". This has given him ample opportunity to discover what a mess the C world really is. He's keeping notes, and may write a master' thesis about it when he resumes work on his software engineering degree. I know that the C community realizes what a mess it's in, because there is now an effort to create a validation suite for C compilation systems built to the ANSI standard. Of course, the Ada community anticipated this need, and has been doing compiler validations all along. Finally, let me quote P.G. Plauger, head of the ANSI C standardization committee, who noted "Beyond 100,000 lines of code, you should probably be coding in Ada." Couldn't have said it better myself.