Re: Ada and robots

[Ken Garlington <Kennie.E.Garlington@lmco.com>]

Huy Vo wrote:
> 
> 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)?

Because it's safer than building it in pure assembly.

You don't _really_ believe systems are "safe" vs. "unsafe", do you?
Systems are _relatively_ safe vs. other systems. There's several good
books on this subject; see (for example)

  http://www.cs.washington.edu/research/projects/safety/www/

> 
> >
> >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.

In Ada, of course, it _is_ required to tell you (see the exception
Storage_Check,
described in section 11.5:23 of the language reference manual). Coupled
with a
good debugging environment, the line number where the check occured will
be
reported.

> 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.

In Ada, it's both.

> 
> >
> >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.

My Ada compiler generates object code, not C, and runs using an Ada
run-time
environment (also written in Ada). I build safety-critical applications
with it.
What Ada compiler are you using?

> 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.

Do you build safety-critical applications?

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com