I took the Ada vs. C++ "trade study" sent out a few days ago,
and tried to turn it into an FAQ for such a comparison. Here
are the results. Totally unbiased, of course ;-).
Comments and (serious) contributions welcomed.
-Tuck
----------------
Q: Don't software costing model sensitivities show that language selection
has little impact on cost?
A: It is true that in some models, varying the programming language has
less effect than variying other parameters. For example:
domain experience (18% improvement)
overall engineering competency (analysts: 29% improvement,
programmers: 30% improvement)
programming language (5% improvement).
However, analyzing these numbers indicates several issues. First,
withing a given organization, domain experience and engineering
competency are relatively fixed. With a given staff in a given
organization, a wise choice of programming language may be
the biggest and most cost-effective lever available.
Secondly, the amount of improvement due to programming language choice
clearly depends on the specific languages considered. If we compare
Modula-2 and TurboPascal, very little effect may be noticed, since both
languages have comparable safety and features. However, if we compare
Ada 95 and C++, the languages differ dramatically in safety and features.
The most basic features of C++ (arrays, pointers, casting) are all
unsafe. C++ provides no support for multithreading or interrupt
handling in the language, and there are no guarantees of thread
safety in implementations of the C++ run-time support, particularly
in the implementation of destructors and exceptions. The basic
features of Ada 95 are all safe, and the language includes built-in
support for multi-threading and interrupt handling with a requirement
for thread-safe runtimes in all validated compilers.
Thirdly, a cost model for traditional waterfall development is
substantially different from a cost model for a more modern,
iterative development process, with interleaved development,
integration, testing, enhancement, requirements analysis, etc.
In the more modern development process, the robustness, capability, and
flexibility of the programming language become more critical.
The more safety and consistency checking built into the language,
the more rapidly errors can be found and fixed, and the more
rapidly enhancements can be made without undermining the consistency
and safety of the overall system. Furthermore, as systems age, even if
they were developed using a waterfall process, maintenance and enhancement
ends up more iterative, and again, the support in the programming language
for safety and consistency checking has a dramatic effect on the
productivity and quality of the maintenance and enhancement process.
Q: Isn't the C/C++ tools market much larger than the Ada tools market?
Doesn't this mean that C++ is a more viable language than Ada
for building real-time systems?
A: The C/C++ tools market is certainly much larger if you include
all PC-targeted tools. However, if you focus just on C++ compilers
that provide thread-safe runtimes, and that have been validated
to some level of conformance with the ISO C++ standard, and
that are designed for use in the real-time systems market,
the size shrinks dramatically. On the other hand, the bulk of the Ada
compiler market is made up of sales of products that provide a thread-safe
runtime, a validation certificate, and support for mission critical,
real-time system development.
The Ada compiler vendor market is strong. Several vendors, such
as ACT and Green Hills, have rapidly growing Ada businesses.
The largest Ada vendor, Rational, is an extremely strong software
company, with Ada as one of their most important product lines.
All the major Ada vendors are focused on the real-time systems
marketplace, and bring extensive expertise to this arena. Most C++ vendors
are focused on the desktop market, and generally have little or
no expertise in the real-time systems arena.
Q: Are there any comparisons which show the relative strengths
of Ada and C/C++?
A: Unfortunately, there are very few "scientific" comparisons of
any sort that compare programming language benefits, in use in
real projects.
One company that publishes records of language productivity and
error rates is Software Productivity Research. Their most recent
records indicate that Smalltalk has the lowest error rates in
the desktop arena, and Ada 95 has the lowest error rates
in the real-time systems arena. An excellent, if somewhat dated,
paper comparing Ada 83 and C was written by Steve Ziegler, formerly
of Rational. This paper was based on bug reports and bug-fix times
recorded over several years on tools written in C and Ada 83.
The evidence showed a striking difference in bug rates and bug-fix times,
with the tools written in Ada having much lower bug rates, and
much shorter bug-fix times.
Q: Aren't Ada 95 and C++ similar in capability?
A: It is true that both languages support both object-oriented programming
as well as more low-level programming capabilities. However, Ada 95
provides many more features to support the development of real-time
critical systems. For example, the following Ada 95 real-time control
features are not provided as part of C++:
1) Portable multithreaded language features, with at least
30 real-time priority levels
2) Thread-safe runtimes, including exception handling and
destructors/finalization
3) Uniform model for interrupt handling support and control
4) Portable bit-level control of representation
5) Packed arrays, with 1, 2, 4, or 8 bits per element.
6) Delays based on both time-of-day and a real-time clock
7) Compiler-provided routines for serializing data types as part
of remote procedure calls or I/O, as well as ability for
user to substitute their own.
Furthermore, these capabilities are available in a portable way,
both on top of off-the-shelf RTOS's (such as VxWorks) as well as
on "bare" machines.
In the area of safety critical systems, Ada 95 provides significantly
more support for building certifiable systems more cost-effectively:
1) Several Ada vendors provide certifiable run-times, including
all documentation required by organizations like the FAA
or the NRC.
2) Because the Ada user can define their own distinct numeric types and
subranges, array types, and pointer types, the compiler can
perform many more compile-time consistency checks. This
can dramatically reduce the static analysis time for a large
safety-critical system.
3) All of the basic features of Ada are safe. The unsafe features
are available only through highly visible unchecked programming
features, which can be localized or restricted as desired to
reduce the certification effort. In C/C++, the basic features
(arrays, pointers, casts) are all unsafe, making it much more
expensive to identify and certify all uses of potentially unsafe
constructs.
4) Commercial tools are available for further automating the
certification process (e.g. the SPARK toolset from Praxis, Ltd.)
5) Ada 95 compilers can automatically enforce project-specific
restrictions specified using the pragma "Restrictions."
Q: What about the future availability of Ada compilers, especially
on "new" chips that are designed in the future?
A: The availability of Ada compilers used to lag behind
behind that of C. However, because of changes in the
technology underlying Ada compilers, that is no longer a significant
problem. In particular, a number of Ada 95 compilers are now based
on optimization, code-generation, and run-time technology that is
shared with C and C++ compilers. For example, the GNAT Ada 95 compiler
makes use of the GCC C-compiler optimizer, back end, and gdb debugger.
In fact, the primary maintainer of the GCC technology is now an employee of
ACT, the company that developed and maintains GNAT. As another
example, the Green Hills Ada 95 technology shares optimizer,
code generator, and debugger with their C/C++/Fortran product line.
Finally, AverStar has just announced a prevalidated Ada 95 compiler
that uses optimized ANSI/ISO C as its intermediate representation,
an Ada run-time built on top of a standard ANSI/ISO C run-time, and
generates debugging information that allows C debuggers to debug
at the Ada level.
With these various options, an Ada 95 compiler for any new chip
will be available in the same time frame as any C compiler for the chip.
Augmenting this sharing of technology with C compilers are
Ada 95 compilers that generate Java byte code files as their
output (e.g. AppletMagic and jGNAT), and include a run-time built on
the standard Java run-time classes. This means that Ada 95 can also
be used in environments where Java virtual machines, or Java
"just-in-time" compilers are available.
Q: Aren't Ada compilers big and slow, and what about the quality of
the generated code?
A: These days, modern Ada 95 compilers run as fast or faster than
compilers for other languages. This is particularly apparent when
compared with C or C++ compilers attempting to compile very large systems.
Separate compilation in C/C++ is based on the lexical-level "#include"
model. This poses a real challenge for avoiding having to repeatedly
read include files in a single execution of the compiler. Kludgey
and non-portable "pre-compiled header" facilities are provided by
some C/C++ compilers to address this performance problem. This
is not a problem for Ada compilers because separate compilation
is based on a semantic-level module importation. There is never
a need to read the same spec more than once in the execution of
an Ada 95 compiler.
Many Ada 95 compilers also have a simplified program library
model that is strictly source-based, eliminating the need for
any large disk-based program library.
Because of changes in the underlying technology, Ada 95 compilers
now generate code as good or better than C or C++ for the same
construct. Because of reduced aliasing concerns, optimizers
can be more aggressive with Ada programs than C programs. Redundant
run-time checks are eliminated by the optimizers built into many
Ada compilers, and of course all run-time checks can be suppressed
program-wide, or in specific modules, with the use of a pragma.
Q: What happens if I don't have enough Ada programmers for my team?
Can my programmers learn on the job? Is Ada being taught in
colleges? Where can I find Ada mentoring?
A: Many companies find that experienced programmers can learn
Ada on the job given a modest amount of mentoring. It turns
out that the Ada compiler itself is an excellent teaching tool,
because the language was carefully human-engineered to allow the
compiler to catch most "silly" errors, while the extensive compile-time
and run-time consistency checks provide guidance on semantic-level
correctness.
Ada is one of the most widely taught languages in colleges. Because
of its Pascal heritage, its excellent human-engineering, and its
support for software engineering principles, it has emerged as a
natural step up for colleges that have taught Pascal in the past.
In a recent survey of colleges using various languages for teaching
programming, those using Ada and Scheme were clearly the most
satisfied with their languages as teaching tools.
Ada mentoring is available from a number of sources. Ada has
an active newsgroup (comp.lang.ada), several extensive web-sites
(www.adaic.org, www.adahome.com), an active user group
(www.acm.org/SIGAda), and a vendor consortium (www.adaresource.org).
Any one of these can supply information on tools and services
available for the Ada community.
Q: Hasn't C++ already incorporated all the good features that Ada has?
A: C++ has some of the same features as Ada, however the features
in C++ are generally less safe, suffer from poor human-engineering,
emphasize writability over readability, or involve more hidden
overhead. It is interesting to see C++-like languages like Java and
Embedded C++ appearing to try to overcome some of the unsafety
and inefficiency of C++. Nevertheless, none of these C++ spinoffs
fully address the fundamentally poor human engineering of C-based
languages, with "=" vs. "==" confusion, missing "break"s, misplaced
"const"s, missing "&"s, arrays indexable by any arbitrary integer or
enum type, no overflow detection, etc.