Re: Ada and robots

[Huy Vo <vo@CTRON.COM>]

jsa@alexandria.organon.com (Jon S Anthony) wrote:
>In article <199706201607.MAA01178@mermaid.ctron.com> Huy Vo <vo@CTRON.COM>
 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.