#92

12.05.21

Christophe Gouiran

Le langage de la fiabilité: Ada

“un prototype en C s’est planté lamentablement quand celui en Ada a tenu face à des comportements inattendus »

Le monde des langages a ses Rolls Royces. Des langages connus, reconnus, robustes, presque éternels et indémodables. Et puis il y a des Tatra (un vrai constructeur automobile, cherchez le): des langages inconnus du grand public mais hautement estimés par les connaisseurs. Aujourd’hui vous pouvez devenir un connaisseur. 

Ce nouvel épisode d’IFTTD – If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, s’intéresse à l’Ada, un langage créé pour être robuste, extremement portable, ne jamais planter et assurer une fiabilité à toute épreuve. Ce langage a été créé pour un usage précis: dans l’aéronautique militaire ! Ça en dit long sur l’ambition et la qualité de celui-ci.

Le D.E.V. de la semaine est Christophe Gouiran, ingénieur logiciel dans l’aéronautique. Christophe vient nous parler de sa découverte avec Ada, ce qui lui a plu dans ce langage et les coups d’éclats d’Ada face au C. Il nous raconte pourquoi ce langage n’a connu que 5 évolutions depuis sa création, soit une tous les 10 ans ! Et surtout, Christophe nous montre pourquoi ce langage est si robuste.

Retrouvez tous nos épisodes sur notre site https://ifttd.io/listes-des-episodes/

Liens évoqués pendant l’émission

Pour contacter Christophe : bechris13250@gmail.com

La société AdaCore

Compilateur GNAT (inclus dans gcc)

Les ressources mises à disposition par AdaCore

Livre en Français sur Ada

Why Programming Languages Matter?

Why ADA is the language you want to be programming your systems with

Gestionaire de paquets

La page Awesome-Ada

Continuons la discussion

@ifthisthendev (https://twitter.com/ifthisthendev)

@bibear (https://twitter.com/bibear)

Discord (https://discord.gg/FpEFYZM)

Facebook (https://www.facebook.com/ifthisthendev/)

LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)

Transcript in english

Bruno Soulez (the podcast host):
Bugs are always present in our work, almost inevitable I would like to say.
With the experience, we resign, we known we won’t be able to cover all corner cases and that, sometimes, it will crash that’s the life.
We only try to make it happen the least often.
However, some developers resist again and again against bug invasion.
They want and they NEED that it never crash.
Can we create a plane guiding system, the air management system for a submarine or a missile trajectory “there is a bug” is not an acceptable answer.
To respond to this need they created a language labelled with a reliability symbol: Ada
But, what is the state of Ada today? Why don’t we all use Ada today? And why being inspired by Ada Lovelace?
To answer those reliability questions, I don’t welcome Pete “Maverick” Mitchell (private joke: it is the main character in Top Gun movie) but he knows about Aeronautic.
Hello Christophe.

Christophe Gouiran (me, the guest):
Hello Bruno.

Bruno:
Could you introduce yourself for people who may not know you?

Christophe:
Yes, I’m involved for almost 20 years in specification, conception, development, test and deployment of aeronautic software.

Bruno:
You are working in this very peculiar domain where doing wrong is almost not tolerated.

Christophe:
That’s it

Bruno:
We heard about some time ago: Boeing had a discrepancy in his elevation system management (i.e he speaks about 737 Max MCAS problem) at the time of plane takeoff phase and we discovered there were only two probes instead of three and there was no mean to check the reliability …

Christophe:
It is worse than that: there was only one probe which gave pitch plane information instead of having at least two.
In the two crashes that occurred, the single probe sent erroneous informations: as a consequence the system slant the plane towards the ground and it led to the crash.

Bruno:
When we are developer in the “civil” world, we known that there are sometimes something may happen, there is not a 100% reliability rate.
Sometimes, for some reasons something doesn’t work.
We only try to mitigate the risk or something like that.
But in your kind of job human lifes are to be considered.

Christophe:
Very often systems in which we can find Ada: if there is a software failure it can lead to human death or the destruction of the flying equipment.
There is no room for approximation.

Bruno:
We spoke about Boing: there is only one probe instead of, at least, two or three to be really reliable.
When you develop, is there also this approach of “probes” which can be done in order to check, are there many programs which do the same thing and you compare results ?
Do you have also this kind of indicator?

Christophe:
Yes, the calculators executing the software are redundant and, within a calculator there are several cards which are well separated.
As such, our code will execute as four instances in the aircraft.
And there are crosschecks between calculators and softwares.

Bruno:
Is it four times the same code which is executed, only in different environments to check that they give the same results?
Or do we ask to different engineers to do they own implementation? They are as many implementations as developers, we all know this.
Or will we ask several engineers to work on the same topic to embed different implementations and be sure that the reliability will be even better?

Christophe:
It depends on the software criticity level to be achieved.
Indeed, for most critical softwares, it is often to involve two different teams and who will implement twice the same algorithm using maybe two different languages.
As a consequence in two completely different ways which avoid to fall in the same case which could lead to the same in the four instances of the software.

Bruno:
We rely on several teams only when the criticity level is extremely high, isn’t it?

Christophe:
Yes.

Bruno:
Yes, indeed more developers are working on the same topic, increasing the cost of the software.

Christophe:
Yes, in this case the cost increases significantly.

Bruno:
We meet today to speak about a peculiar because, obviously, when you are working at such criticity levels, you won’t use PHP or JavaScript because it is not reliable enough I can imagine.
Even C is not reliable enough, so a specific language has been specifically created for the purpose.

Christophe:
Yes, the language we speak about today is Ada.
It is a language which has been propose to answer to request for proposal made by American Defense Department around end of 70s.
At his time, they had to maintain several software, written in a myriad of languages.
They wanted to switch to only one language and, if possible, as robust as possible.
A French team won the request for proposal among almost 30 responses.

Bruno:
The main goal was to standardize the code base and to avoid using several languages but, instead, to use only one which could take in charge a bit more?

Christophe:
Yes, that’s it.

Bruno:
It was not mainly about reliability, instead a will for standardization?

Christophe:
There were two goals: they requested standardization but at the same time to get more reliability compare to existing languages.

Bruno:
OK.
So it’s a French initiative.
Who is behind Ada language?
Is it a private company?
Is it a specific consortium?
Do we speak about three developers who did a brilliant language?

Christophe:
I know it is a private company.
If I remember well it was Bull and I think they made an alliance with another one.

Bruno:
You make us a big jump back in time!
Bull: a lot of people don’t even know what it is.
Bull was a software or hardware company?

Christophe:
I don’t really know.

Bruno:
I’m on Wikipedia at the same time: Bull is a software and hardware company created in 1931.
They have been acquired by ATOS in the meantime.
I didn’t hear about Bull for a long time!
The paradigm was a will for robustness, isn’t it?

Christophe:
Yes, that’s it.
At his time Ada was revolutionary because it proposed:
Packages, a bit like namespace in C++, with a private part in a pseudo object way.
Real enumerate type (not considered as an int like in C)
Genericity
Exceptions
Concurrency: possibility to have several threads of execution and a mechanism to get safe and concurrent data access.
All of this integrated in the language.

Bruno:
You speak about enum, concurrency and exceptions: In a language which want to be robust it is obvious.
It is mandatory to handle exceptions. We are on calculators which need reliability and speed so concurrency is also important.
Reliable enums are also important.
However you spoke about package.
With my web background I must say that package lead to import of external code bases.
But it is also an open door to some kind of instability when you use some external code?

Christophe:
It doesn’t mean the same thing: it is called package but you will not import any open source code found on GitHub or whatever.
Instead, we can speak about namespace, a way to separate the code in several components independent from each other.
Which an information masking to avoid exposing private data to everyone.

Bruno:
OK, I see.
Indeed it allows you to have a code which is well structured, so it eases the refactoring or this kind of things.

Christophe:
For the beginning of the 80s, it was a very ambitious language, maybe a bit too much because compilers providers had difficulties.
Software engineers at this time through really that Ada would kill C.
We are on the scope: system language, low level.
It was so superior (compared to C).
But due to big difficulties at the beginning and expensive compilers (in opposition to C compilers which were very often provided for free with UNIX systems).
Furthermore, those compilers generated binaries a bit slow during their execution.
It didn’t help to promote the language.
It is no more true today.
At the beginning of 80s it was maybe too much ambitious given poor computer capabilities.

Bruno:
A language robustness can’t be only done through a library or a language on its own.
The robustness is also achieved thanks to which problems, flaws, failure at execution the compiler is able to find.
It is surprising the compiler was not provided with the language!

Christophe:
I’m too young to know all the details but it’s what I have read and heard from older people.

Bruno:
Ok, but today if Ada compilers are as good as C ones in terms of speed, reliability and simplicity, why Ada is not yet used a lot?

Christophe:
It is a language designed to take in charge industrial problems, specifically in railways, aeronautic, spatial, medicine, nuclear.
They are not very trendy.
That’s what explain why the language, still today, is confidential.

Bruno:
Ok.
Can you tell us how you met Ada, the language not the woman J

Christophe:
I have been passionate by computer programming since the age of 11.
At the beginning I wrote programs in BASIC language, then a bit in assembly and I discovered C.
It was end of 80s so there was no resources available.
I learnt on my own.
I met Ada language at university, it was mid-90s.
I have been enjoyed by the clean and strict aspects of the language.
It enforce you to think about the software architecture and to write clean code (or else it won’t compile).
In C it is possible to write not so clean code.
With Ada it is almost impossible to write crappy code.
It has a syntax which looks like Pascal: very verbose but easily readable and non-ambiguous.
It’s perfect for code reviews.
For junior developers it is a language which is easy to learn, at least for basic concepts.
If a junior developer programs in C he will fall in all the pitfalls: pointers, out of bounds access in arrays
With Ada, we are very well guided by the compiler which detects a huge quantity of problems during compilation.
It’s a bit the ancestor of Rust language.
When writing the classical “Hello World” program it will be easy.
But as soon as it become more and more complicated you will face compiler.
It is here to help you write good behaving code.
We almost feel someone is here and monitor we don’t do mistakes.

Bruno:
Ok.
Is there a hard learning curve, or the compiler helps you improving linearly and smoothly?
How to apprehend Ada?

Christophe:
I would say the learning curve could not be easy.
In fact it depends on which languages we used before.
If we only developed in C/C++ before switching to Ada, it is mandatory to completely change the way to think about problems.
Ada language is not permissive at all!
Its syntax is completely different.
There are concepts (memcopy, and many other low level concepts) which exist in Ada but using another approach.
During first time programming in Ada it is a bit complicated.
I have an anecdote to tell:
I discovered Ada at beginning of 2000s and use it during four years.
Since then I used C++, Ruby, Python, C, I was no more using Ada.
I came back in aeronautic domain since 2018.
In my department the C language predominate all developments.
It is the language chosen by default.
With one of my colleague, when we started the project we are working on, we fought and gave arguments to choose Ada language.
We told that this language would help us to write more robust code and this robustness with be achieved more easily than with C.
As a proof, we had to write a prototype and the deadline was a month later.
A third colleague wrote it in C and I had to write it in Ada.
A test executable (for which we didn’t have source code) was provided: this executable generated network messages encoded in a proprietary protocol and we had to decode and display content of received messages.
As I didn’t develop in Ada during almost 15 years it has been complicated to use it again.
During two first week it has been very difficult.
I was able to rely on AdaCore support (our toolsuite provider): they were very efficient, professional and fast.
So, even a junior Ada developer can rely on AdaCore expertise.
On last two weeks I made huge progress and, finally, finished my prototype one day before the colleague developing in C.
When we executed our prototypes, we noticed that the test executable sent unexpected messages not described in the specifications.
The C prototype crashed and my Ada one was robust even in those cases.
In fact, during the development I had to take into account error or unexpected or invalid messages.
As a consequence my prototype was robust when dealing with those unexpected messages.
This proof of reliability led to the choice of Ada language for the project.

Bruno:
Ok, but how a language can be more robust?
With Ada you had to anticipate those peculiar cases.
A C developer could also anticipate peculiar cases no?
For me robustness depends on how the developer anticipates peculiar cases in his code.
I can achieve to write robust code even in C.
How a language can provide robustness mechanism?

Christophe:
Even an experienced developer can make errors.
When we develop in C, the language is so permissive that if we make a mistake in the code it may not be detected by the compiler.
We will notice the error during execution.
Sometimes we don’t notice there is an error when we write in an unexpected memory area.
It will be noticed if one day we try to access to memory area and the bug will appear but we will notice it months later!
Ada language (and its runtime) provides a lot of safety:
This kind of error will surely be detected by the compiler.
If not detected during compilation, it will be detected during execution: softwares written in Ada embed a runtime which do a lot of checks during execution.
Writing or reading out of an array bounds lead to the raise of an exception which must be handled.
If it is not handled the program will stop but we have the possibility to handle those kind of errors which, in C, are difficult to anticipate.

Bruno:
There is also an automatic error handling mechanism during execution in an Ada environment?

Christophe:
That’s it.
It could be frightening to known that the compiler generates a lot of check at execution.
We noticed that there is not a big performance penalty.
It is quite surprising (that the execution is still efficient).
On my first project in Ada, the software was written in millions of code lines and ran on Motorola 68000 processors.
It was impressive to see all the processing done by the processors.
We get a high level of reliability (almost) without performance penalty.

Bruno:
Between a plane and a helicopter there are a lot of differences, obviously, but there are also a lot of communalities.
Especially on software side.
I can imagine a navigation system will the same for a plane or for a helicopter but the hardware won’t be the same, or do you use the same hardware?
Do you rewrite the code to adapt it to a different hardware?
Does Ada permits this kind of similarity in different environment or am I completely wrong in my question?

Christophe:
I don’t work on both planes and helicopters, only one of them.
Therefore I don’t know how to answer this question.
What I can say is that Ada language is extremely portable.
We are working on software which must last during decades and on which we are engaged on a guaranty period which can last up to 50 years.
This is impressive!
During those 50 years we may have to change the hardware …

Bruno:
… Just on this guaranty period. Its impressive 50 years of guaranty.
Does it mean you know the software will work whichever arise or you will update the software, on security patches or something like that?
Or is it both?

Christophe:
It is both: we can apply security patch during the project lifetime but we may also be forced to change the hardware because the provider doesn’t support it anymore.
We therefore must do what call a retrofit: we will change some hardware.
And where Ada is very interesting, if we take care of some technical details during the development, porting to the new hardware is eased.
We can switch from a Little Endian to a Big Endian processor for example without many efforts.

Bruno:
I’m reassured by your sentence because I though with Ada it was done with a finger snap.
You say to us there are still some details to take care about and after that it is done without many efforts.

Christophe:
Yes, things to anticipate: the language provide in its standard some basic types (integer, float) like in many other languages.
In fact it is discouraged to use those standard types because they depend on the hardware architecture.
Instead, if we define our own types, the software is completely independent of the hardware architecture.
Then it becomes very interesting in order to ease the portability.
Another aspect is to handle endianness: we can use directives (i.e Pragmas) on the data structures to ask the compiler: please handle this data structure in Big Endian in memory.
Therefore, on a Big Endian processor, it will be a no-op and on a Little Endian the compiler will generate swapping operations for the developer.
Those kinds of difficulties must be done by hand in C.
Therefore, there are good chances that we will write less code than in C and, at the same, rely on an outstanding portability.

Bruno:
Ok,
You speak about a guaranty on several decades.
Does the Ada language evolves on a very slow rhythm?
Or, on the contrary, there a lot of evolutions?
Or since its creation, the language has almost not changed?
What is the life of Ada language?

Christophe:
It’s a language which evolves very slowly.
Since beginning of the 80s, there have been only four evolutions, i.e nearly every 7-10 years.
The first version was Ada83 which brought all I said at the beginning: packages, genericity, etc.…
Then we got Ada95.
It’s the version I’m using in my project: we are aBrunoolutely not in a professional sector which tries to use trendy languages J
So, Ada95 added object oriented concepts and the possibility to extend packages but I won’t go in deeper details.
Then, Ada2005 which added containers and the possibility to use and extend interfaces (like in Java)
The last version to date is Ada2012 which added contract programming, iterators, some syntactical sugar to be able to write more concise code.
And there is a version in progress which is called Ada202X and should be officialised in 2022.

Bruno:
Do we speak about major versions but there are minor ones in between?
Or not at all.

Christophe:
No, only those major versions.

Bruno:
Ok,
I imagine this is linked to aeronautic industry which can’t follow language evolutions, even every three years?

Christophe:
Yes, as you said, it is linked to this industry which is quite conservative.
For softwares written in C, we are still using C89.
We often say that we are using technologies which are 20 years late compared to existing technologies.

Bruno:
Yes but, as contrary, your software can work during twenty years?

Christophe:
That’s it.
Twenty years is a minimum.

Bruno:
It’s a feat to achieve that!
I can imagine there are confidential data.
You told us that you are working on helicopters.
I suppose we won’t know whether you work on military or civil ones but I imagine we can use Ada in environments which are less “confidential defense” that others.
When you are an Ada developer do you have access to a community which is very active?
Or, due to this exclusive aspect, you are alone with your Ada reference book?

Christophe:
When I began with Ada almost twenty years ago there was a very little community.
I hope I won’t upset Ada developers in the audience J
There were newsgroups which are still existing and alive.
Since then AdaCore company, which is our provider, has made a big effort to put in place a community.
For example there is a technical blog.
They also organize an annual programming contest which is called Make With Ada and which rewards the best projects.
There is also a subreddit.
In stackoverflow we can use the [Ada] tag and I saw there are about 2000 questions which is not so bad …

Bruno:
… At the same it’s nothing: JavaScript or PHP developers should say that 2000 questions it is not meaningful.

Christophe:
There are user groups: Ada Europe, Ada France
There is an online tutorial (once again provided by AdaCore)
Ok compared to mainstream languages it is quite confidential but I was positively surprised by this ecosystem compared to beginning of 2000.

Bruno:
Is this community involved in the language evolutions? Even if there are few evolutions.
Are those evolutions driven by a consortium or else anybody can participate?

Christophe:
I don’t have an immediate answer.
I think there is a page on GitHub where people can propose language evolutions.
I’m not quite sure: I must check.

Bruno:
I can imagine that evolutions coming from “outside” of the consortium are strictly checked before being integrated into the language?

Christophe:
As you said: they are stickly checked by the normalization comity but also by compiler providers.
Because they must integrate the evolutions in their compilers.
Knowing that all Ada compilers on the market must be certified and pass a huge test suite.

Bruno:
You just spoke about tests.
How do we test in your peculiar aeronautic domain?

Christophe:
We can use unit tests, we do system tests on test benches and code reviews.

Bruno:
Is there a heavy or very precise process which enables to test a lot of things?

Christophe:
We use test environment which is provided by AdaCore.
There is an unit tests generator.
There is also a tool which can check several coding rules.
For example, we may forbid to use recursive functions or with a cyclomatic complexity level a bit too high.
I also like that the code is organized the same way in all source files.
We have a pretty printer tool.
We also have a building tool like Make.
And we have an IDE called GNAT Studio which is pretty cool.

Bruno:
I though in Ada we could have a tool which could ensure reliability of the code.
Because it is part of such a language no?

Christophe:
Mmm yes.
I know since Ada2012 we can use contract programming.
For exempla a function, if its input data follow some rules, can guaranty that it will always return the same kind of results or something like that.
It’s a topic I don’t really known.

Bruno:
You said you are less familiar with Ada2012 and we told there are major versions every 7-10 years.
As the language evolves does the industry adopts those evolutions quickly?
Or else, even Ada2012 is not very used even today?

Christophe:
I could not say whether Ada2012 is used a lot or not.
I can give another example: the project on which I worked in 2000 is still using Ada83.
In this kind of projects we don’t take the decision to upgrade the language version during the project lifetime.
Fortunately or unfortunately we stick with the version chosen when the project started.
In my current project on which we use Ada95 : I bet we won’t change during the project lifetime.

Bruno:
OK, I see.
Knowing we are on projects which have a 50 years lifetime, you will miss almost 5 Ada versions.

Christophe:
The paradox, despite using Ada95, I have the feeling to use a modern language.
Compared to other projects where C is used, I feel that I can use additional features.
I don’t feel restrained.

Bruno:
You spoke very positively about Ada because, I can guess, it’s a language you love since a long time.
Could you give us a painpoint, something which a pain to do in Ada? Which is complicated and that we do more easily in another language?

Christophe:
Because it is very strict, it can be very hard to compile a source file.
We can have a long tough time trying to compile a source file which seems to be correct but it won’t pass the compilation phase.
With 2 years of experience its ok for me but for newcomers it’s something they are not used to.
There is another painpoint : the compiler, in case of warnings or errors, often displays reference to the Ada reference manual which is sometimes difficult to understand.

Bruno:
About recruitment.
I think we are very few to know this language.
Is it very difficult to find Ada developers?
Is the need for Ada developers very low compared to available developers?

Christophe:
It is very hard to find Ada developers.
I think it is a language which is less and less taught around the world.
However AdaCore, through an educational program, provides resources to more than 300 universities around the world.
Some of my colleagues used Ada a long time ago.
Apart from them I don’t know anybody else programing in Ada.

Bruno:
Therefore you recruit developers and train them on Ada?

Christophe:
That’s it.
Even when it’s time to make technical decisions, decision-makers don’t choose because they don’t even know it.
That’s why a lot of projects around me are developed in C.

Bruno:
Do you think Ada is a language worth studying?
If yes, is it advised to study another language before Ada?

Christophe:
I’m not sure it is advised to study another language before.
It may be chocking depending on which language(s) you used before.
Studying it after having used scripting languages which are not typed or even C may be chocking!
It’s the first language I studied at school.
It can be a very good language to study first because it enforce you to be rigorous.

Bruno:
It’s a language which added object programming quite recently …

Christophe:
… in 1995
Compared to C++ it’s several years later.

Bruno:
Can we really use this language for a personal project?
If I want to develop in Ada can it be done easily or must I buy licenses?
A compiler to buy or something like that?

Christophe:
To work on non-commercial software, GNAT compiler is freely available.
Once again AdaCore which mainly contributes to this compiler.
In fact it is integrated in the gcc compiler.
For commercial projects, it is mandatory to buy GNATPro.
Using various resources provided by AdaCore it’s very easy to start.

Bruno:
In which cases I could choose Ada for a project?

Christophe:
If you project matches at least one of following points then Ada may be a good solution:
Detect bugs as soon as possible when they are not yet expensive to fix
Software must be robust
Resist against cyberattacks
Long term maintainability
Portability
Be able to work at “high level” without performance penalty.

Bruno:
You just say something which needs to be explored.
You speak about resistance against cyberattacks.
It’s a language created in 1983 which only 4 evolutions.
In 1983 cyberattacks had nothing in common with today.
How such an old language and with very few evolutions can be more resistant against cyberattacks than other languages today?

Christophe:
Due to features it provides in the domain of memory protections.
We can ensure very easily a data is valid before reading its value.
When we must process something coming from the external, it is very easy to ensure that my variable(s) don’t carry invalid values and which could make me “jump” in a random memory area.
Even if I forget to check data validities before using them I won’t be able to read unintended memory area because it will be check during execution.
There are a lot in software written in C which doesn’t provide safety guards against unintended memory access.

Bruno:
Thanks a lot Christophe
One last question: are you using taBruno or space (for code indentation)

Christophe:
Space!

Bruno:
Thanks a lot Christophe

Christophe:
Thanks Bruno

  • DESIGN & DEV
  • CROISSANCE
  • CONTENU
  • DATA LAB
  • FINANCEMENT
  • CONSEIL
  • DESIGN & DEV
  • CROISSANCE
  • CONTENU
  • DATA LAB
  • FINANCEMENT
  • CONSEIL
  • DESIGN & DEV
  • CROISSANCE
  • CONTENU
IFTTD est soutenu par CosaVostra

Cabinet de conseil et agence digitale qui aide ses clients à innover, à penser différemment et à générer de la croissance grâce au digital. Nous serions ravis d’imaginer votre prochain projet innovant.
On en parle ?