Lambda the Ultimate

I typically approach language wondering what I can learn from it. Especially when I won't get to use it for production code. So, I guess a better question is what can Ada teach?

Based on first glance, it appears that Ada was designed to be a Software Engineering language, rather than just another programming language. It has a similar look to Eiffel, or more likely the other way around.

There must be something great here if Ehud always refers to it.

WRT Eiffel, Betrand Meyer was also a big fan of Ada but disliked the OOP extension of the languages. Eiffel was his attempt to bring the Ada philosophy to the OO world.

Ada is a traditional imperative language, so it can serve as a good yardstick when talking about mainstream languages. The language was designed from the outset for efficient execution (including hard real time work) and safety -- combined with the facilities needed for general purpose programming.

Ada favours code readability over code writing. Obscure notation and confusing constructs are not the norm. A simple example: both short circuit boolean operators and regular operators are in the language, each with a meaningful name (Eifell does this as well, IIRC).

Many industrial strength projects use Ada. This is important since valid empirical research in SE is quite rare...

The reason I like Ada is that compared to other 3rd gen mainstream languages it is quite high level and provides many useful and interesting language features: the language has an expressive and safe type system (not buffer overflows for Ada programmers!); parallelism is built into the language and has rich and well defined semantics; the module system is quite advanced (though ML's is better); the generic programming facilites are useful and versatile.

Meyer's object to Ada's OO features seems a bit ungenerous. Sure, Ada83 lacked proper OOP facilites (there was no inheritance), but Ada95 addressed this problem. The Ada model is a bit strange, I have my own reservations about it, but it is usable, and in fact has its own advantages.

Don't take all this to mean that I find Ada to be a perfect language. Far from it. But it is quite well designed in most respects, and deserves wider recognition.

I also found a book on Ada for Linux programming here<a/>.

These may be good resources for someone who wants to learn/study the language.

"The lessons of Ada remain irreplaceable, and it is a pity that many of the O-O languages of the eighties and nineties did not pay more attention to its emphasis on software engineering quality. However obvious, this comments is all the more necessary because the occasion for discussing Ada in this book in often to contrast some of its solutions with those of O-O development -- as will again happen several times in this chapter. The resulting critiques of Ada techniques should be viewed less as reproach than as homage to the precursor against which any new solution must naturally be assessed."
p1080 Object-Oriented Software Construction

but Ada95 addressed this problem

"The basic concepts of object technology, for all their power, are strikingly simple. Ada 95 may be the most ambitious effort so far to make them appear complicated."
p1095

"The basic concepts of object technology, for all their power, are strikingly simple. Ada 95 may be the most ambitious effort so far to make them appear complicated."

Thanks for the reference... This is one of the most idiotic statements I ever heard in the context of programming languages. Notice that it appears in page 1095 of a book written by the same author which tries to explain these 'basic conecpts of object technology'.

Even though I have my own reservations about Ada95's OOP facilites, I think their best feature is that they elucidate some (but not all) of the subtle issues that are conviniently hidden by those talking about 'strikingly simple' concepts. For example: dispathing operations, binary methods, class-wide vs. type specific operations etc.

Part of the reason Ada (among all other compiled OO languages I am familiar with) doesn't succeed in elucidating all the subtle issues that come with OO, is that the concepts of OO technology defy this goal. And, as later work shows, Meyer's solution based on specifying contracts inside the language is very far from being a complete solution.

Regarding which, later readers might consider the recent discussion on composition filters, a more advanced or generalized notion of DbC.