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: 103376,5ecb5248e650e812 X-Google-Attributes: gid103376,public From: Huy Vo Subject: Re: Ada and robots Date: 1997/06/24 Message-ID: <9706242128.AA09652@stealth.ctron.com>#1/1 X-Deja-AN: 252316751 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: comp.lang.ada Date: 1997-06-24T00:00:00+00:00 List-Id: jsa@alexandria.organon.com (Jon S Anthony) wrote: >In article <199706201607.MAA01178@mermaid.ctron.com> Huy Vo writes: > >> >Um, this just means Ada _labels_ unchecked conversion as dangerous. In C >> >it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?) >> > >> Safe or not safe, it looks like Ada programs can crash on the field like >> a previous poster admitted. The worse thing is that it leaves no trace >> as to what leads to the crash. And other posters have to come up with >> ugly 'C hacks' to provide traceback of Ada programs. There goes the myth >> that Ada programs need no debugging. > >a) No one is dumb enough to suggest Ada programs are by nature some >how bug free. So, you are just giving a silly strawman Cool; Ada is not as safe as I thought it was; so, when I board a Boeing I should think twice. By the way, aren't there components on a Boeing that are based on 8 bit processors that can't take C let alone Ada. So what is the justification of insisting on building supposedly safe systems (the Boeing) with a mix of safe components (Ada) and unsafe ones (C and assembly)? > >b) Trace backs or not are _implementation_ dependent. Plenty of C >implementations have nothing to offer here either (put together with >the fact that most have absolutely worthless compile time diagnostics >and you have something that basically offers zero support). As a C programmer, I know it better than anyone; so I have been religiously checking every malloc()'s return and proceed accordingly. What do you do when you call new and new fails? You rely on the runtime system telling you what line it fails? Unlikely, since the runtime is not required to do this. How many of you actually have a customized "out of memory" handler that indicates what exactly the offending line? Error checking is an attitude; it's not a feature of the language. > >c) In this particular case (fiddling with machine level >representations) the most you can conclude from your "comment" is that >neither has an advantage over the other, i.e., for this _particular_ >case, you claim that it's a wash. > >d) Even in HW interfacing there is a _lot_ more going on than the >actual machine level fiddling. This work invariably requires >(implicitly or explicitly) higher level abstractions. > >e) No one is dumb enough to suggest C has high level abstraction >capabilities such as found in Ada. On the contrary, C constitutes the low level base for Ada programs, the work horse, the "unsafe" layer (NT, UNIX, LINUX, etc...) without which it's impossible to build "safe" applications. The lack of high level abstraction doesn't hurt C a bit. C provides me with every component that made this post possible: the editor, the operating system, the networking software/firmware. I don't believe in C because everyone (well, almost) writes in C; I believe in C because it works just fine for me.