John McCabe said:

> IMHO This last sentence is the crux of the matter - if you are layering
Ada
> applications on top of an unreliable operating system (say Windows 2.0,
3.0,
> 3.1, 3.11, 95, 95OSR2, 98, 98SE, NT, 2000), it is very easy to produce an
> application that isn't necessarily significantly more reliable than what
> you're trying to replace.

That depends very much on your tools. If you write Windows applications all
in Ada using a thick binding like Claw, you will get an application that
most likely is quite a bit more reliable than the one being replaced. Why?
Because an thick binding encapsulates a lot of knowledge about the
platforms, and can include work-arounds to many common glitches. When I'm
dealing with some awful Windows headache (and we run into them a lot), I
always tell myself that at least other Ada programmers using Claw won't have
to deal with this problem.

Probably even more important is that Claw (and presumably other thick
bindings as well) spends a lot of effort on early error detection and
reporting, by checking validity of arguments, and especially by raising
exceptions when Windows returns an error. None of the Microsoft bindings do
that, so Windows programmers often ignore errors; that necessarily decreases
reliability.

Of course, Claw can't turn Windows into an ultra-reliable system; especially
as the dynamic behavior of the system is essentially undocumented. But it
can make a very significant difference in the reliability of the result.
Indeed, I would expect OS-independent bindings to be able to do even better,
by being more detached from the Windows environment. (But of course they
cannot generate an app that really have the look and feel of the Windows
application.)

OTOH, if people write their GUI in MFC and the body of the app in Ada, and
then complain it isn't very reliable, well, the presence of unreliable
code/languages of course will drag the whole thing down: An application
can't be more reliable than its weakest link.

                                Randy Brukardt.