Ada – a modern programming language designed for large, long-lived applications – and embedded systems in particular – is set to get some extensions in its next incarnation Ada 2006. There is a talk here, highlighting the most important changes (eg. cyclic type structures, Java-like interfaces, standardization of the Ravenscar tasking profile, container libraries, etc.). Updated drafts of the standard are available here. For general information about Ada there is a Wikibook Programming:Ada.
Ada 2006 Draft ISO Standard available
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Outside of the defence industries who is using Ada ? I don’t hear much about Ada elsewhere.
Few years back there are attempt to create an OS purely using Ada. Anybody knew what have heppened to it?
I think it is hosted on sourceforge, but it didn’t get past planning.
As for Ada itself, it’s use rigorous specification and strong support for invariance, make is quite nice.
It’s really hard to make a mistake with it, if it compiles chances are it works close to flawlessly, if you bothered to constrain things.
It seems GCC support for it is still lacking, I could be completely off on that, however.
…my favorite language is changing again.
Ada 83 was my fav.
No, GCC has a frontend for Ada, says so on the site:
Currently the main GCC distribution contains front ends for C (gcc), C++ (g++), Objective C, Fortran, Java (GCJ), and Ada (GNAT).
Ada is the software Esperanto, a language designed to be “the” language which no one uses.
Even the govt has moved on, so please don’t tell me about the billions of lines of Ada out there that will benefit from this, that horse was beat dead over Cobol.
ada is the perfect language for businesses. it is very very very strongly typed and structured. it is very very safe. object oriented… the only problem is that you can not find developers who know it. most beginners hate it because i is so strict and most experienced programers hate it because it is so strict.
but when you are building bomb software and must be available systems, ADA is perfect and required.
Syntax is like pascal.
And i think big commercial companies use it like Boeing for computers on their jets.
They actually updated their web site in March so I guess they haven’t given up yet:
http://adaos.net/home-2004-12-23/
the goal of Ada is to make programs that will not crash. Has there ever ben a buffer over run?
Simply having a front-end means dick. They have one for java, but it’s not a complete implementation by far, not to mention it doesn’t support Java 5.
There is more to language support, than parsing and generating code. Not to mention that those to alone can be quite difficult to do well.
“They have one for java, but it’s not a complete implementation by far, not to mention it doesn’t support Java 5. ”
GCJ is now mature enough to compile major applications like Apache Jakarta and Eclipse, Java 1.5 features are being worked on but until there is critical mass it wont really matter.
No, it’s not that mature. For instance, it still can’t reliably compile Xerces or JING — stock. The libraries aren’t all that completely, try to do anything with the class loader and interesting things start happening.
It’s mature enough to compile the things Red Hat cares about. Soon it’ll improve even more; however, I’m not sure how ingenuous it is to claim that it’s mature in the categorical fashion that you are or seem to.
But that’s not the point I was making, I’m saying that simply parsing and generating code isn’t everything, so a front-end means little. Though, it does carry more weight now thanks to the foundations laid by 4.0.0.
The integrated Ada95 in gcc has been on the level of the seperate gnat distribution since gcc 3.4. The one in 3.2 and 3.3 still had several problems, but 3.4 and 4.0 are quite nice.
Who’s using Ada: http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
A# (Ada for .NET): http://www.martincarlisle.com/a_sharp.html
MaRTE OS is written in Ada and C: http://marte.unican.es/
Ada World is a good Ada resource: http://www.adaworld.com/
First of all – Ada is not dead. On the contrary – in high integrity and safety critical settings Ada is constantly gaining market share. And there are reasons for this trend.
Its strict and coherent typing system makes many common mistakes quite unlikely. In addition to that there are (optional) runtime checks. Buffer overruns, off by one errors, etc. are gone. And you get meaningful error messages instead of segfaults.
Those programmers who complain about the strict typing have choosen the wrong profession. Programming is not about hacking together some unmaintainable solution by taking short cuts in the typing system. Ada is very expressive *because* it lets you define types and subtypes with ease whose contraints are enforced by the compiler or runtime.
Speaking of maintainability. Ada’s syntax is much clearer than C’s or C++’s. Even though – being intelligent humans – programmers can learn the traps and pitfalls of C/C++ and understand what lines like: void(*f(int,void(*)(int)))(int); mean, in the context of large systems it results in unmaintainable systems far to often.
Especially for embedded systems, Ada has nice supporting features. You can specify, how many bits a type should use. So when you write: type byte is mod 256; for byte’size use 8; it is guranteed that byte’s values are in the range of 0 .. 255 and it uses 8 bit to represent this type. You don’t have to stick with implementation specific sizes. In addition you can specify exactly the layout of records (structs in C) leaving no questions about padding. So programming portable solutions is a breeze. Those may not be issues for you when developing x86 only but in the embedded world there are many more microprocessors and operating systems than the popular ones everyone knows.
There are many many more features of Ada that are useful and nice. There is built-in concurrency, generics have been there since at least 1983. For those interested in success stories – there are some videos here:
http://www.gnat.com/aa_about.php
and you may consult other Ada compiler vendors for their stories, eg.:
http://www.ddci.com/programs.shtml
http://www.ghs.com/
http://www.praxis-his.com/sparkada/
http://www.aonix.com/
And finally — I am not aware of limitations in the Ada frontend of GCC.
I know that it isn’t really related to Ada, but as Linux’s kernel grew, the weak typing of C induced Linus to create a tool (sparse) to add ‘strong typing’ checks much like Ada provides, and sparse found many errors..
So next time you compare the easy C and the hard Ada, think about “sparse” and what it means.
It is a pity that Ada’s compiler were so expensive otherwise the language may have had a chance to compete when it started.. but as the IT is very much a fashion industry and that Ada is now perceived as ‘old’ it has very little chance of becoming ‘hot’ again..
Using external typechecker tools for C/C++ can be quite expensive. Free ones such as Splint are not covering all of C99 (and nothing of C++) and often produce false positives. Even if you use C’s type system correctly it is still much too weak. Semantically types such as int or char are overloaded very often and since a typedef is just an alias you are on your own to stick to conventions. That may be workable in small projects but does not scale very well.
“the goal of Ada is to make programs that will not crash. Has there ever ben a buffer over run?”
No that I can think. But errors are just possible in Ada, see the Ariane 5 disaster, which happened because of a type conversion error, since people had reused an old Ada module in a new Ada program. This is why Bertrand Meyer had just kept saying “withouth DbC you can’t have safety” for years.
I also recall the original Ada author left the design committee for Ada95 since he felt the direction it was going was completely wrong, did he ever reenter the game ?
Anyway, I disagree with “Those programmers who complain about the strict typing have choosen the wrong profession. Programming is not about hacking together some unmaintainable solution by taking short cuts in the typing system”.
You have fallen in the usual “ah, I want static guarantees!” mood that makes no sense. People have been building complex systems withouth the static safety of Ada for long time.
Missing static typing gurantees have been proven completely differen from having maintainable code (not saying it is useless, just unrelated).
“But errors are just possible in Ada, see the Ariane 5 disaster, which happened because of a type conversion error, since people had reused an old Ada module in a new Ada program.”
Errors are possible but you have to actively do something to produce one with Ada. The default behavior is almost always safe. Regarding Ariane 5 — the explosion did not happen because they reused an older software module, but because the underlying model did not fit reality anymore which has nothing to do with reusing per se. If your model is wrong you are lost. So, why do you relate the Ariane 5 desaster to Ada? Do you relate the loss of the Mars Climate Orbiter to C? Here is an excerpt of the relevant Ariane code section (formatting is lost on this forum):
…
declare
vertical_veloc_sensor: float;
horizontal_veloc_sensor: float;
vertical_veloc_bias: integer;
horizontal_veloc_bias: integer;
…
begin
declare
pragma suppress(numeric_error, horizontal_veloc_bias);
begin
sensor_get(vertical_veloc_sensor);
sensor_get(horizontal_veloc_sensor);
vertical_veloc_bias := integer(vertical_veloc_sensor);
horizontal_veloc_bias := integer(horizontal_veloc_sensor);
…
exception
when numeric_error => calculate_vertical_veloc();
when others => use_irs1();
end;
end irs2;
As you can see, they explicitely suppressed numeric errors for horizontal_veloc_bias. They had proven for Ariane 4, that values would never raise this error. But as I said, the model did not fit reality with Ariane 5, leading to a value 5 times as high as with Ariane 4. The overflow caused undefined behavior since it was not checked. But you should note that it would have been possible in Ada to catch such circumstances, whereas in C there are never any runtime checks.
“You have fallen in the usual “ah, I want static guarantees!” mood that makes no sense. People have been building complex systems withouth the static safety of Ada for long time. Missing static typing gurantees have been proven completely differen from having maintainable code (not saying it is useless, just unrelated).”
I don’t see why it makes no sense. If a software system is safety critical I do want “static guarantees” maybe even in form of proofs. Just because people are able to build systems under worse conditions does not make those desirable. You imply that static guarantees are bad because people built systems without it. How lame is that!? Why do you think that almost all life critical systems in avionics are developed in Ada? Do you think the engineers are in a “mood that makes no sense”? Do you even believe in technological advancements? Strict static typing is of course not sufficient for maintainability. But the expressive power of Ada’s type system improves maintainability a lot because semantic ambiguities are rare.
The air force has developed a .NET version of Ada called A#. This is no joke. See here: http://atlas.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html
Ada is also a great teaching language. It has all the construct you need to properly teach high level programming both for imperative and OO.
It also has the great advantage as a teaching language that most people haven’t used it before so they don’t come in with existing language specific
bad habits.
It is for these reasons that Glasgow University Computing Science department uses Ada as one of its teaching languages. It has done since 1995, the year after I graduated (I was part of the group that helped choose Ada as the replaement for Pascal for the first two years of programming). Glasgow Uni also uses Haskell, Java, and C.
Ada had a revival after the 95 standard, but becasue of the explosion of Ariane 5 (see http://en.wikipedia.org/wiki/Ariane_5_Flight_501), people decided there is no point in using a language designed for embedded systems if it allows a rocket to explode….
Even if a few projects use Ada, it is a living dead language with very little support and products available in the Industry.
Shame really beceuase it is a good language, but the extra work needed to use it is not worth it as it is not a safe language after all.
And it’s not a 2006 standard that will reverse the trend.
out of curiosity, does any one know any other failures of ada besides ariane 5? or is a single instance of reusing code that shouldn’t have been reused all it take to doom a language in the eyes of critics?
I don’t understand how anyone could say Ariane 5 is a failure of Ada (see my answer to “verbat” above). The problem with Ariane 5 would have come up in any language (and even more there). This has been debated a thousand times and I am astonished that everytime the name “Ada” is mentioned, people draw their attention to the completely unrelated issue of Ariane 5. Get over it!
The comment “Shame really beceuase it is a good language, but the extra work needed to use it is not worth it as it is not a safe language after all.” is bogus. I use Ada at work and at home and I’m quite sure there is no “extra work” compared to using C++, Java or anything else.
As for “safe language”, compared to what? I think Ada is far safer than any other popular language with respect to how most problems are discovered at compile time rather than run time.
There are at least eight different Ada compiler vendors and I think that is plenty of choices. GNU Ada (GNAT) is both excellent and free, but you can buy first rate commercial tech support from AdaCore if you think you need it.
All languages have their pros and cons…
Ada is safe and fast but has probably the most complex syntax off all languages on this planet. It’s OO is very much like add-on. Since Ada is usually used in real-time systems there is no garbage collector included in most implementations.
Eiffel has design by contract and is fast but all compiler implementations have their own variation of the standard library. As far as I know there are no threads available in GNU/SmallEiffel.
C++ is powerful and has innumerable libraries available but it’s easy to get into memory problems.
Java is probably the most portable language available with outstanding security but it’s performance and resource usage are not very good.
C# is Java clone (even if officially denied). It has nice syntax but there are open questions about Microsoft patents. Performance seems to be only little better than in Java.
Ruby is great dynamic OO language with a lot of real innovation but lacks libraries, performance and english documentation.
Python also lacks performance but has good community and a lot’s of libraries, bindings and documentation. However it’s OO is like playing with hashtables. Python has very clear syntax and good portability.
On paper Ocaml seems to be almost perfect language in terms of performance and reliability but it’s functional syntax turns many away. OO performance is on same level as in Java.
I wish I won’t start language wars here. 😉
— Limiting my reply to the Ada section of your comment since that’s the topic of this thread.
First, I would highly appreciate it if you could give an example of Ada’s “most complex syntax off all languages on this planet”. I am interested because I found Ada’s syntax to be very clear and easy to read. So please, enlighten me!
Then – if time permits – could you elaborate a little about the “add-on” nature of Ada’s object orientation? Please share your great wisdom with the mere mortals, will you?
View a class definition in Ada and compare it to other languages and you should understand my point. IMHO, class definitions are both *weird* and *complex*.
“I don’t understand how anyone could say Ariane 5 is a failure of Ada (see my answer to “verbat” above). The problem with Ariane 5 would have come up in any language (and even more there). This has been debated a thousand times and I am astonished that everytime the name “Ada” is mentioned, people draw their attention to the completely unrelated issue of Ariane 5. Get over it! ”
sorry, should have been more explicit i meant “ignoring ariane 5 are there any actual cases of failings of ADA, as opposed to a case of code being reused when it shouldn’t have been”
i am actually on your side.
View a class definition in Ada and compare it to other languages and you should understand my point. IMHO, class definitions are both *weird* and *complex*.
Must be a point of view thingy because I’m with Martini. I find Ada to be clear and simple. I find class definitions to be neither weird nor complex. It is certainly LESS weird and complex than C++.
That is my opinion, and people are allowed the privilege of not sharing it. That’s why there are so many languages. Otherwise, we’d all still be using Forth written with sector editors.
Regarding Ariane 5 — the explosion did not happen because they reused an older software module, but because the underlying model did not fit reality anymore which has nothing to do with reusing per se. If your model is wrong you are lost. So, why do you relate the Ariane 5 desaster to Ada?
Because it is an example that static checks like those found in Ada are not enough. As mr Meyer would say “this can’t happen in Eiffel”.
You imply that static guarantees are bad because people built systems without it. How lame is that!?
Really lame. And I did not said that. You said that people who complain about strict typing are dumb, and supposed a relation with unmaintanable software. I said this was dumb, and you’ve not proven the contrary.
And as you probably know by being an Ada developer, there are people that think that even the full Ada language is too unsafe, think for edxample of Spark.
Sorry, Timo, but Ada does not have the most complex syntax of any language (perchance you are thinking af ALGOL68?).
Certainly, it was a much more complex language than its peers at the time (C, Pascal, FORTRAN, COBOL), but C++ is a far more complex language than Ada95 (and it does less). It also had very stringent compiler requirements (it supported generics (templates) back in ’83). As well, nobody could call a compiler an Ada compiler unless it was compliant with the standard (so no partially Ada supporting compilers were allowed – unlike C compilers at the time which had various levels of compliance in terms of features and libraries).
The only things that C++ can do that Ada95 cannot are: multiple inheritance (but multiple interfaces can be inherited – like in java), forward declarations (this is being addressed in the latest standard).
Ada has as part of the language: multithreading (yes, no add on hack to make thread safe programs), strong type safety, true user type declarations, ability to specify the size and layout of types, it provides extensions for real-time programming, distributed executation, numeric precision, database operations, etc. It also interfaces cleany with various languages (C, FORTRAN, COBOL – interfacing with C++ requires exporting C++ functions with an extern C).
Ada is a very good language and I like it more than C and C++. It’s principle downside is that it has little 3rd party support (so basically, you are mostly doing stuff from scratch). It support for templates (generics) is far superior to C++’s. It package partitioning is much better than C++’s namespaces.
As for me, I’ve been programming in C for about 20 years, C++ for about 10, and Ada95 for about 5.
rr
(1) Design by contract would not have prevent the Ariane 5 desaster, no matter how strict your pre- and postconditions are formulated (and I remind you that there were correctness proofs for this particular piece of software based on Ariane 4 data). Last time I checked there was still a difference between reality and software.
(2) You claimed I am in a mood that makes no sense demanding static guarantees, which is quite a puzzling critique from someone suggesting design by contract methodology. I said that Ada’s typing model alone is not sufficient for good maintainability but it does make it easier because of less semantic ambiguity. Codifying everything as integer or float types or using function arguments of type void* do create maintainability burdens.
(1) yes it would have, see the related article from Mr. Meyer.
(2) you had this
non strict typing:unmaintanable software=non strict developer:dumb developer”, I just say this is wrong.
I would not suggest using Smalltalk for the A380 control system as I would not suggest Haskell for system administration scripts, I’m just saying that maintanable software is mostly independent of static guarantees.
I am referring to “Design by Contract: The Lessons of Ariane” by Jean-Marc Jézéquel, IRISA and Bertrand Meyer, ISE.
While they claim that DbC would “probably” prevented the problem and give 3 reasons, I disagree with them. Here is their reasoning:
(1) “Assertions (preconditions and postconditions in particular) can be automatically turned on during testing, through a simple compiler option. The error might have been caught then.”
The problem with this is, that there simply was no testing that covered this particular issue. The Ariane 5 flight profile was not included in the IRS system specification. So it was not available to the contractor. And Ariane 4 flight data would not violate any condition (I remind you again that there already were correctness proofs available). And the integration testers assumed that Ariane 4 testing was enough in addition to the contractors testing. So I say it again — there was no testing that could have triggered this issue in this particular case.
(2) “Assertions can remain turned on during execution, triggering an exception if violated. Given the performance constraints on such a mission, however, this would probably not have been the case.”
Indeed. Ada provided the appropriate runtime check but because the system load had to be below 80% they switched several tests off. Otherwise an exception would have been raised.
(3) “But most importantly the assertions are a prime component of the software and its documentation (“short form”, produced automatically by tools). In an environment such as that of Ariane where there is so much emphasis on quality control and thorough validation of everything, they would be the QA team’s primary focus of attention. Any team worth its salt would have checked systematically that every call satisfies the precondition. That would have immediately revealed that the Ariane 5 calling software did not meet the expectation of the Ariane 4 routines that it called.”
Given that this particular software system was developed by an contractor who did not have the appropriate Ariane 5 flight profile its “QA team” could not have found the problem. I don’t want to argue against DbC in general but in this particular case it would not prevented the problem. As I said, the integration team didn’t properly test and review the contractor’s contribution based on the false assumption that the relevant code was already tested by the contractor itself and previous Ariane 4 testing. So the problem is more related to organisational problems.
Finally I point you to a better critique of the claims made by Meyer & Co.:
http://home.flash.net/~kennieg/ariane.html
It is common practice on the market that whenever there is a problem with high public attention, there are those seducers who claim that they have the solution ready at hand, whether it is appropriate or not. I consider the Meyer text to be part of such tactics.
“you had this non strict typing:unmaintanable software=non strict developer:dumb developer”
Here is what I said: “Those programmers who complain about the strict typing have choosen the wrong profession. Programming is not about hacking together some unmaintainable solution by taking short cuts in the typing system. Ada is very expressive *because* it lets you define types and subtypes with ease whose contraints are enforced by the compiler or runtime.”
I blamed programmers who complain about strict typing because I assume that someone who is complaining about something doesn’t like it. And strict typing is reasonable. And don’t confuse strict and static typing. In the relevant context I don’t say anything against dynamic typing (although I don’t like it), because dynamic typing can still be strict. And I said something about unmaintainability and taking short cuts in the typing system and here I had those void* arguments in mind. I hope I stated the issue with reasonable clarity now.
>Then – if time permits – could you elaborate a little about the “add-on” nature of Ada’s object orientation? Please share your great wisdom with the mere mortals, will you?
Wow. This is taking me way, way back. I can, however, corroborate the fact that the first spec of Ada had no OO in it. I don’t believe that OO was even coined as a term back in ’83 when the first Ada spec was out.
So I believe there is some credence to the fact that Ada OO was a of an “add-on” nature.
Well, I have to agree with you that the first Ada standard (1983) did not cover object orientation. This was added in 1995. As far as historic developments are concerned one can certainly speak of “add-ons”.
But this alone says nothing about how it feels to do OOP in Ada. I wouldn’t say it feels broken or somehow limiting for instance. Of cource Ada is (like C++) a multi-paradigm language, but I consider this an advantage and not like the original poster suggested a disadvantage. Some OOP purists consider every language other than Smalltalk to implement OOP in a somewhat limiting way.