Ada 95 is the revised version of Ada. It has been standardized by ISO back in 1995: it was the first ISO standard object-oriented programming language. Ada 95 is a very powerful object-oriented, concurrent programming language.
Ada has some kind of a bad reputation in some circles because it originally was designed to satisfy the US Department of Defense's need for a safe, modern, and structured programming language back in the late seventies and early eighties, and because it is often used in military projects. It is also often used for safety-critical software, for instance in nuclear power plants, which some people object to. This also may contribute to Ada's acceptance problem. It also is not a toy language: it's not small, which leads many people to believe that it is difficult to learn. More on that below.
Ada is also very well thought of by some other (albeit smaller and more closed) circles. It is among the top choices for the development of realtime software, embedded software, high-integrity software, safety-critical software, and so on. In general, people who need to produce reliable software sooner or later find that Ada 95 meets many of their demands.
Regardless of whether one likes the circumstances under which a programming language has been born or the things it is used for (and there are many, many civilian projects using it, too, e.g. in aviation or medical care or even business software), I think this whole debate is futile. If it suits your needs, use it, if it doesn't, use another programming language that does fulfil yor requirements. After all, programming languages (and computers, for that) are just tools and nothing more.
But what is Ada 95 like? Let's see if I can characterize it somewhat:
==confusion, no ill-defined constructs line
k = a[k++];, and so on.
All this combined accounts for the fact that the number of bugs that occur in production software written in Ada (or Ada 95) is an order of magnitude less than the number of bugs found in software written in languages with a less powerful checking semantics.
One thing that the Java-savvy among you readers out there may miss in Ada 95 are reflective capabilities. Ada just doesn't have them.
However, reflection is a double-edged sword: yes, it may come in handy sometimes and enable things that otherwise would be just plain impossible to express in a programming language. But it is also a very advanced feature. Besides the fact that many programmers not well-versed in that area of the language may just not understand what's going on, it also makes the behavior of programs generally more intractable if used carelessly.
In my Java development (and yes, I have written parts of huge, distributed, commercial applications in Java), I have found it rarely necessary to use reflection, and when I did, I did so with great care, extensive documentation, and only in isolated, well-defined places. Most of the times I was tempted to use Java's reflective capabilities I was able to come up with an equally proper way of doing the same thing without reflection, just using standard mainstream OO paradigms.
Nonetheless, some kinds of reflection in Ada can be done. A very limited form is
shown in my
Util subsystem in package
Util.Reflect. More serious
reflective work can be done using
ASIS, the Ada
Semantic Interface Specification, an Ada 95 library giving access to the semantic
structure of Ada 95 code.
No, it is not. True, it is a large and powerful language, but it's really not that complex as many people believe. If you're somewhat familiar with object-oriented concepts even that part of the language should be no problem to understand. The way classes and objects are expressed in Ada 95 may need some getting used to by people familiar with other common OO languages such as C++, Java, or Eiffel. For me (with an Oberon and Oberon-2 background) the Ada way was very intuitive and no problem at all. If you're unfamiliar with concurrent programming, though, I'd recommend you follow a course on the subject (preferrably, but not necessarily, in Ada 95). Not that tasking in Ada were overly complicated -- but concurrent programming in general is full of pitfalls that may trap the unwary.
My personal experience shows that a computer scientist or software engineer with a solid background and understanding of the principles of programming can learn Ada 95 on-the-job in a matter of weeks, at most months. That's not more than for other languages; being familiar with all the intricacies and pitfalls of, say, C, C++, or Java takes at least as long. If you're interested, just give it a try!
BTW, there's even a very good free Ada 95 compiler called
GNAT. It is part of the GNU
compiler suite and runs on many platforms, including Windows and Linux.
Online tutorials may be found on
I offer some of my Ada 95 code for download. Most of this is distributed under the GMGPL, the "GNAT-modified GPL".
You won't find an extensive list of links here as other people have done that already:
On both sites, you'll find amongst many other useful things online copies of the ISO standard for Ada 95 (on AdaPower; on AdaHome), and also of the Ada 95 Rationale (on AdaPower; on AdaHome). These are the ultimate references for questions concerning the language, but they're not intended for beginners! To learn the language, check out one of the books on Ada 95.
Note, by the way, that the Ada 95 standard is an exception; normally ISO standards are not available for free but must be bought for dear money from ISO. The copyright for this standard, however, lies not with ISO but the U.S. D.o.D, which has assigned it to the public domain. (Well, legally speaking this may not be absolutely correct (I'm no lawyer), but that's what it amounts to.)
Other information on Ada 95:
package) and for object-orientation (
tagged types), Ada 95 currently has a problem to declare mutually dependent "classes" in separate packages. John Volan discusses this at length in his "With"ing FAQ. (An Ada 95-specific ISO working group is working on a (I think, rather elegant) solution for this problem, but nothing's been decided yet. BTW, C++ doesn't have this kind of problem because its encapsulation facilities generally are weaker and one can forward-declare classes.)
Copyright © 2002 by
Thomas Wolf. All rights
TW, Jan 15, 2003