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=0.6 required=5.0 tests=BAYES_40,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,1042f393323e22da
X-Google-Attributes: gid103376,public
From: NKSW39B@prodigy.com (Matthew Givens)
Subject: Re: Any research putting c above ada?
Date: 1997/04/16
Message-ID: <5j19g5$jae@newssvr01-int.news.prodigy.com>#1/1
X-Deja-AN: 235144795
Distribution: world
References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <u912rj925.fsf@kastle.com>
  <5ijb0o$ajc@ns1.sw-eng.falls-church.va.us>
  <334d3da5.14386594@aplcen.apl.jhu.edu>
 <2senchydgk.fsf@hpodid2.eurocontrol.fr>
  <3359e813.340466234@news.pacificnet.net> <33508283.56dd@aonix.com>
  <33526280.62b3@gsfc.nasa.gov> <5ivths$pv2@huron.eel.ufl.edu>
Organization: Prodigy Services Company  1-800-PRODIGY
Newsgroups: comp.lang.ada
Date: 1997-04-16T00:00:00+00:00
List-Id: <comp.lang.ada>


afn03257@freenet2.afn.org (Daniel P Hudson) wrote:
>
>The problem with C and C++ is, even with exceptions, when witting 
mission
>critical software, C(++) leaves a *lot* UNDEFINED. This translates 
>to a deferenced NULL pointer could cause a defibrillator to go off
>on a healthy patient and cause a heart attack rather than prevent one.
>You can scream you hold the programmer responsible all you want, but
>that is of no comfort to the man sitting there watching his death 
charge
>up to give him a jolt. I'm not saying it is impossible to write bad
>Ada code which may do the same, but it is a LOT less likely. Deny it
>if you must to defend your own opinion of C as the perfect language,
>I don't care, but facts are facts and denying them won't make them
>go away. However, the library itself is defined well. It is the actions
>of the library that worry me. C's undefined behavior is great for
>portability, but bad for safty. You are not going to have both in a
>langauge, you might not have either in some. Assembly lanaguge, for
>example, is NOT portable or safe. It makes it no less useful than Ada
>or C. It only means you should know WHEN to use your tool
>[whether it is C, Ada, Modula, Basic, Eiffel, or whatever] and
>WHEN not to. Always is not the CORRECT or LOGICAL solution.

I would never, I hope, pretend that one language is perfect for every 
situation.  In fact, I argue the opposite quite a lot.  C is good at what 
it does, very good.  Try writing a compiler or OS in Ada.  You can do it, 
certainly, but it's easier and  more natural in C.  Why?  Because that's 
what C was designed to do!  Ada was intended to develop embedded systems, 
and is good at it.  No question.

But something that is good in one situation is bad in another.  This 
means that both C and Ada have their places.  Neither is objectively 
"better" than the other, because you can't compare them objectively.  You 
have to look at the strengths and weaknesses of a language, not just the 
weaknesses.  You also have to look at what the language is being used to 
do.

How many grahics intensive computer games are being written in Ada?  
That's really out of it's intended realm, so I would hazard to guess not 
many.

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>