From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: Ted Dennison Subject: Re: C/C++ knocks the crap out of Ada Date: 1996/02/19 Message-ID: <3128B515.41AA@escmail.orl.mmc.com>#1/1 X-Deja-AN: 140069677 references: <4etcmm$lpd@nova.dimensional.com> <4f4ptt$a1c@newsbf02.news.aol.com> <4g1b7n$l5@mailhub.scitec.com.au> <3124B2F3.6D21@escmail.orl.mmc.com> <4g8mjm$bce@mailhub.scitec.com.au> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Marine Systems mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ x-mailer: Mozilla 2.0b6a (X11; I; HP-UX A.09.01 9000/750) Date: 1996-02-19T00:00:00+00:00 List-Id: Ramses Youhana wrote: > > Ted Dennison (dennison@escmail.orl.mmc.com) wrote: > > Quite true. But having "cleaned up" both, I can tell you Ada is MUCH > > easier to detangle. > > That's interesting. Is this due to the language itself, or the way > the programs were written or both? I have had to "detangle" other I'd say due to the language. > peoples C code on many occasions. Those that were well written > were very easy to fix, however, the majority were incredibly poorly > written. These were very hard to fix, and in many cases, the code had > to be re-written. All of these problems were due to the poor design and > coding habits of the programmer and not the C language. I am wonderring > how much protection Ada provides against bad programmers and engineers. > I know that C doesn't provide much protection. This is one reason why > it is important to design the system first (on paper) before one starts > coding. Well, for the quailty developers you've got a language with integral facilities for information hiding, and strong typing to preserve the integrity of their objects. For your average developers, you've got a language where pointers are NOT used for arrays and parameter passing. And when pointers ARE used, they are NOT assignment-compatable with integers and characters and pointers to objects of another type. This cuts out a lot of the most common C errors. You also have a language where array bounds are checked. For those of you who follow Unix security, you know that the single most common cause of Unix security holes is due buffer overflow conditions on arrays wihtout range checking. Hackers know about Unix's C shortcommings, and exploit this lack of range checking to insert their own code into a running Unix job with root privs. If Unix were written in a language with range checking, a whole cottage industry of Unix security consultants would be put out of work. Also, proper use of typing will prevent errors like garbage data propagating through a system (sometimes a network!) and crashing a seeminly unrelated routine (eg: when it tries to index by that value). The strong typing has one other effect. The extra pain involved in hosing the type checking encourages developers to think through their typing scheme ahead of time, and to choose wisely. Thus for code written by average and above average coders, debugging typically means finding the cause of some Ada exception that occured, and adding code to handle that case. For your poor developers, (who will often STILL write code that has to be rewritten), you have a language where aliasing is difficult and obvious when done. You have a language that forces separation of interfaces and implementation. This not only makes important interface information easier to locate (without having to wade through tons of irrelevant code), but it also discourages poor develpers from hosing of your "objects", by hiding the details of their implementation in another place. You also have a language whose package-based scoping rules imply that the rotten code is generally confined to one source file. This one source file can usually be completely rewritten, WITHOUT changing the interface to the rest of the code at all. In practice, the only real way to write spaghetti code in Ada is the infamous "generic-ghetti". This involves using multiple levels of nested generics (usually with a lot of procedure parameters) in a structure so complex that it is nearly impossible to tell what the instantiated code does. (Here we often refer to it as "Frankel-ghetti", in honor of an STGT developer who managed to write an example so bad that the DEC Ada compiler simply spat out an "I give up" error message.) Once C++ folks start to figure out templates, they'll have this problem too. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison |