Re: ada and robots

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Joe said

<<That has not been our experience, especially when debugging of tasks
containing procedures in different languages.  The common (and inadequate)
solution is two independent and isolated debugging systems, one per
language, with no way to follow the thread of execution whereever it may
go.  We can use such a system, but why would we?  Getting systems to work
is hard enough as it is.>>

Note that you were responding *specifically* to a point about Ada 95. Since
you are certainly not as far as I know a customer of ACT, you must be using
other Ada 95 compilers (and more than one) to make such a judgment about
the common solution (which certainly is not true of GNAT, and not true
of at least some other Ada 95 compilers with which I am familiar).

Can you please be more specific, or are you speaking from general (incorrect)
hearsay without any real experience -- I guess the latter. 

As for the tools market, what makes you think the Ada and C tools markets
are disjoint. Many tools that work for C work just fine for Ada (in an open
systems context such as the approach GNAT uses, it would be surprising if it
were otherwise). For example, it is perfectly possible to use a CM tool like
Clearcase with GNAT. Yes, it is nice if a little bit of tailoring of these
tools can be done. For example, Purify works pretty well with GNAT, and a
fair number of our customers have used it successfully. However, it would
work better if a little bit of specialization work were done. The Ada market
may not be able to support the investmeent necessary for duplicating the
production of tools like this, but it can and will support the investment
for their specialization where this is worth while.

Another example, GDB is a pretty competent multi-target multi-language
debugger. Even in its completely Ada-unknowledgable form, it is usable
with Ada 95 (usable enough that most of the developers on the GNAT project
have never used anything else -- this is largely because of its very
effective ability to call user level functions, so that debugging functions
can be placed in the image). GDB is a large and complicated program, with a
lot of complex target dependent stuff (e.g. it needs to know about stack
formats). We certainly do not have the resources to duplicate this work.
But we *do* have the resources to specialize GDB so that it knows more
about Ada. The current Ada mode is a first step in that direction, but a
lot more is coming in this direction.

Similarly, a lot of work has been done on visual interfaces for GDB (there
are several, including DDD, GDBTK, PMGDB, and a new one that we are creating
from scratch). We could not afford to duplicate this entire collection, but
it is highly desirable to have a choice, since personal tastes vary a lot
in this area. We can afford to do a little Ada specialization (and it is
interesting to note for example that the folks taking care of DDD, though
certainly not Ada mainstream people, have on their own steam made some
nice modifications to DDD to better accomodate Ada).

Yes, Ada is a much smaller market than C++, so it is not worth while for
tool makers to spend huge amounts of effort rebuilding their tools from
scratch for Ada. It is however by no means a zero size market, so a number
of tool makers are quite interested in capturing this incremental market
if it means doing relatively small amounts of incremental work on their
existing tools.

This is what makes it practical for Ada 95 to develop and maintain a strong
set of tools, even if and though Ada 95 remains a small market compared to
C++ or Java or whatever language-du-jour is.

Robert Dewar
Ada Core Technologies.