 My next duty is to introduce the next speaker, Jean-Pierre Rosin, that's myself, hello. And I'm going to give you a general overview of the EDA language for those who never heard about it before. So unless you have any questions about the organization, okay, that's fine. Everybody's got a raffle ticket, yeah. Okay, there it is. Okay, let's go. Before I start, I'm working for a company called EDA Log. I have wrote some flyers too. And so that's a company doing training, consultancy, and et cetera, but EDA. So you may think, oh, that guy is telling us how nice EDA is because that's his business. Now, in fact, the other way around. In a previous life, I was a teacher in an engineering school, and I was responsible for the teaching of programming languages and compilers. It's because I thought that EDA was a very nice language that I made my business with EDA. So it's not because it's my business, it's the other way around. So when talking about EDA, you have dates and numbers. EDA is not an acronym. It's the name of EDA Byron, Contest of Lovelace. And she was, she's famous for being the first programmer in history. She worked on Babbage Machine, if you heard about that. And so she could never run her programs because the machine never worked. However, they were later recorded in PL-1, I think, and worked right out of the box. So the first program had no bugs and the first programmer was a lady. We've changed that since. The first version was in 1983. Don't tell me it's very old. It's much more modern than C and it's approximately the same time that C++ appeared. So it's not older than most used programming languages nowadays. At that time, it was quite revolutionary by already having in a well-designed set, exception, generics, tasking and many features that you could not find in the same language. At that time, there was, my mouse is jumping. And I think, yeah. 1995 was a major rework, introduced object-oriented programming, a kind of mechanism, synchronization mechanism called protected objects and a way of organizing the various modules of your design into a hierarchy called hierarchical libraries. By the way, it was the first language, it was the first object-oriented language to be standardized at least at an international level as an ISO language that was about three years before C++. 205 brought some improvement from other languages, especially the notion of interfaces that work mostly like Java interfaces, and also some more and more libraries and services that are added to the language in the form of extra libraries. In 2012, which is the latest revision to date, EDA has been going more formal with contracts, preconditions, post-conditions, what is called programming by contract. So it's moving to be more and more formal and more and more, not exactly provable but checkable at runtime for various conditions. So, especially here, it's my pleasure to say that EDA is a free language. It has not belonged to any big industry or any major brand. It is, first of all, an international standard and it's entirely controlled by its users. The evolution of the language is made by a group from ISO and those belong to various companies and all work to improve the language. You have three compilers, GCC has an EDA version. You know, GCC is all languages compilers, so what we call GNAT is actually the EDA front end to GCC and it's like all of GCC distributed as free software. You also have proprietary compilers, that's normal, that's a world of business. Many free resources are available and you have a dynamic community so you have youth groups and groups on all the usual social media. So, you may think that you don't see much EDA. That's true but that's because the people who use EDA are not generally those that you see everywhere. I mean, if you take the TIOB index, for example, you'll see EDA completely down in the ranking. Because the TIOB index is based on the number of software on GitHub and the popularity in the social networks. Now, Euro control, for example, has 2.5 million lines of EDA. I don't think they are on GitHub. They're not, of course. And when Thales designed civilian and military radars, they're not on GitHub. And the software for the Ariane 6 rocket is not on GitHub and so on. It's an industrial language and those people don't put their software on GitHub. So, as a physicist, when you measure something you have to know what you are measuring. The TIOB index is a very good index of the popularity of the languages for hobbyists, but not for industrials. So, it doesn't prove... So, here are a few examples of where you can find EDA software. The TGV has lots of EDA software in it. The A380 and many other airplanes at Airbus and Boeing. The automated metro line in Paris. That works so well that it has been sold to the Americans. It's also the system in the automated subway of New York. This was the Rosetta probe that explored the comet. It worked for 10 years and then woke up and achieved successfully its mission. This is a brand luxury yacht that has been entirely written in EDA and so on. So, why would you use EDA? In general, EDA forbids a lot of things. Most languages tell you, oh, our language is very good. It allows you to do a number of things. With EDA, the EDA people will tell you, oh, language is great. It forbids you from making many errors. It's a language for safety. It's a language for software that works out of the box. So, when I hear people complaining about buffer overflows or the attacks or those kind of things, this problem has been solved since 1983. So, there is no reason nowadays to complain about buffer overflows if you have one. You just have to do it. You don't use the proper language. And so, as I mentioned, the idea of EDA is to check as much as possible at compile time. So, when you write something in EDA, in general, it will never compile the first time. The compiler will always find something that's not correct in your code. The good news is when you run it for the first time, it very often runs out of the box. And that is very satisfactory. Okay, I write something. The compiler helps me run, write the test, run. Okay, it works. Go to the next problem. So, what's important in a language is not what it allows. What's important in a language is what it forbids, okay? Because that's where the safety comes from. If you have a language, like C, that allows everything. Well, that's normal. It's a portable assembly language. So, you have to take up the responsibility of safety. If you allow everything, there is nothing you can prove. The only thing you can prove is when you have rules that forbid some incorrect constructs. So, here is a little picture that summarizes the shape of EDA. You have a big concrete basis. It's a language. The syntax is based on Pascal. EDA was designed after competitive competition. Readability was a very important criteria in that competition. All the languages that made it to the half-final had a syntax based on EDA, on Pascal. Honestly, I don't understand why all the new languages find it obligatory to have a C-based syntax. C, don't misunderstand me. C is a very good low-level language. Certainly the best low-level language. The requirements for C was to be a portable assembly. And as a portable assembly, it's very good. We'll see that EDA, we work at a different level of abstraction, okay? But having a high-level language with a syntax of C, I don't understand quite well the benefits. Anyway, we will have lots of examples. On top of that, you have a very strong typing system. I think, yes, that's it. So, the typing system is really the backbone of the language. Everything is directed after the notion of type. So almost every other language appears as weekly type compared to EDA. So we'll have some examples. And then you have a number of pillars here that are featured of the language that serve each precise goal of software engineering. Packages is a way to split your program into well-defined independent modules. It's strange that few languages address that question of modules. Even namespaces, for example, in C++ are a way to control visibility. But you can add anything at any time to namespace. So there is no control of the modularity of it, okay? Here we have the idea that we build an application from software components with someone who provides the software component, someone who uses the software component. Exceptions, well, now it's quite common in most languages, so I assume you know what it is. That the way of having runtime safety. In EDA, everything that can happen that's bad will be translated into an exception. The requirements were that anything that happens at runtime will translate into an exception. Because when you are writing software for a missile, for example, you cannot run after it and press Ctrl-Alt-Dell, okay? The missile has to care for himself whatever happens, okay? So even memory relation in C code, for example, that you call from EDA, will be translated into an exception. Or an IO error or an overflow or whatever you have will be translated into exceptions. Generics, well, they were a bit like templates in C++, or should I say templates in C++ were inspired from EDA generics. It's a way to have reusability in the presence of strong typing. If you write an algorithm for a certain type, you cannot choose it for another type. So it's a way of parameterizing your software so you can use it on various types. Multitasking is an integral part of the language, and because EDA is also used for embedded software, you have a number of features that allow you to access the low level without losing the high level approach. And all that is supporting the roof, the programming methodology. That's very important. EDA was designed to support methodology. Now, nowadays some people say, well, it's important to have good methodology. Nobody would dare saying the opposite, of course. However, some people say, well, we have a good design methodology so we don't care what the coding language is used after that. In EDA, we say, no, why would you stop the methodological effort when you go to the coding phase? If you have a language that actively supports the methodology, which means that you have a direct traceable connection between a methodology and a coding language, then you can trace it all over. And there is also an effect. It's hard to prove but we witness that every day that if you have a design error in your methodology and your language matches the methodology, then a design error will translate into something that doesn't compile. I cannot tell you how often I think people come into my office saying, well, that language, I wrote that, it won't compile. Look at what you've written. Is it consistent? Don't you think that there is something that's misguided here? Oh, yes, I'll change that. And when you think the design error, magically it compiles. So because your types, all the features matches exactly the object of your methodology. So the idea of EDA is to further the methodological effort into the programming language, including now, since 1995, of course, object orientation. And you have the dog houses on the side here that are called spatial-need annexes because not everyone has the same needs. And because every EDA compiler is validated against a very difficult validation suite, if you put something in the language, you must provide it. No subset, no supersets is allowed. By the way, I have here the EDA reference manual if some of you want to have a look, but don't take it, it's fine. And although nowadays you have it on the web, it's nice to have it on paper sometimes. So extra services that are not required from all compilers are put into the annexes for special purpose. So I'll talk later about the distributed system annex. You have some an annex for real-time systems, an annex for system programming, an annex for information system, for numerics, and so on. So people who don't care for numerics do not need to bring in all the numeric stuff. That's what it means. So when you look at it, it looks like an improved Pascal. It looks very classical language, but when you use it, you discover that it's much more different from other languages than the syntax seems to show. Okay, something to understand is the building block approach of EDA. You've heard that EDA was an object-oriented language. You look at the list of keywords, surprise, surprise. The class is not a keyword in that language. Actually, the idea is to make building blocks and to construct paradigms by assembling building blocks. So I'll give you an idea about what it means. You have the Lego, the primeable against Lego approach. If you have primeables, you have very nice pictures that are designed for a special purpose and cannot be used for anything else than their intended purpose. They're ready to use, but if you want to make something different with it, it's not possible. If you take a piece of Lego, a single piece of Lego, there is nothing you can do with that. Just that, that's not funny, okay? But if you assemble those pieces together, then you can make very simple things like this one, or very sophisticated ones like this one, or even this. So the EDA approach is to have various building blocks and you assemble them to build your paradigms. So let's see at some EDA. As I mentioned, it's a Pascal-like syntax, so if I have a type color and I want to iterate over it, I can say for say in color, loop. And every construct, every statement is terminated by a matching and loop. So you don't have curly brackets beginning and that you need if you have only one statement and so on. You always have a clear beginning, a clear end. And an interesting property of that syntax is that if you copy a line and paste it somewhere else, it won't introduce syntax errors. You cannot say that of many other languages. Also, the control object, I don't say variable, C here for example, is considered a constant by the rule of the language. You cannot change it in the middle of the loop and it's local to the loop, so you are certain that you don't have any remaining value that you use incorrectly after that because you don't have it after that. You also have the usual while loop. You can give a name to a loop. So you can give a name to a loop and if you give a name to the loop, you must repeat it at the end and that's very convenient because when you have several end loop, end loop, end loop, end loop, you can document which loop you are closing. Don't tell me, oh yes, that's easy. I can do that with a comment because you never know if a comment is true. While here it's checked by the compiler and therefore you can rely on it. So you have the usual if, else if, else if structure. You have a case statement so for the C language people, it's a switch, the equivalent of a switch case, but there is a very nice feature of Ada given the type of I, did I mention Ada was strongly typed? Yes, I did. You know all the possible values because the type in Ada is a set of values with a set of operations. It's mathematically well defined. And knowing the set of value, the compiler will check that every possible value is provided in the various branches of the kit statement. Or you can have one of those to cover all the remaining ones. And that's a very important feature of Ada. Users love that feature because in general you avoid when others close. And therefore if you change anything in your type, add new values or change it in any way, the compiler will automatically tell you all the places where change needs to be made. If you add a new value and forget some case statements, it will not silently ignore it. It will tell you, oh, here, you forgot to give me the value. And instead of chasing a bug for two days, you'll immediately fix the compiler error and that will be all. Also Ada makes every attempt to allow you to work directly with high level objects and not go down into loops, into loops, into loops over the individual elements. For example, there is a notation called aggregates. If you want to write the value of a matrix, you can write it directly like that. You don't have to assign to individual elements. For example, here I have a piece of a linked list. So in my head, I create a node initialized by a certain value. And the next element is itself a node initialized by a certain value. And, well, we'll stop there so the next element is null. You describe globally a structure. You don't have to go down deep in the structure with every element. And needless to say, all the consistency of the values is always checked at compile time. So if there is anything that's not correct, you'll know immediately. So I set strong typing. What does it do? Imagine I have the age of a person. Well, when you design a type, types in EDA are abstractions of real-world objects. Well, you cannot add the age of a person to a number of rows. It's meaningless. So in EDA, you define a type and every type is different. If you have here something that says... If it says type is, it's always a different type that's incompatible with any other type. So if I have the age of a person and the number of rows in a building, I can use the appropriate values here. But if I try to mix them up, it will simply not compile. Tell that to a six-year-old boy and he will look at you with glass eyes saying, well, it's been a certain number of years, even at that age, that he's been told that you don't mix apple and orange. But EDA is the only language that allows you to check that at compile time at language level. So the idea, when you design a software, you should always do it this way. First, you model the problem space. There you have ages, you have flaws, you have things like that. And then you have to map those high-level types to a machine level where you have only byte, ints and things like that. That's the language level. With other languages, you have to do the mapping. Even with supposedly high-level languages like Java, C++ and so on, all the integer types you have are the machine types. So you have to do the mapping. The new thing with EDA is that EDA gives you access directly to that level and therefore it's the compiler who does the mapping. It means that it relieves you from many portability problems because that level is completely machine-independent. Therefore, the compiler chooses, the compiler knows the machine and it will always choose the appropriate representation for your types. But your types are by nature machine-independent. Packages, I mentioned that. You still have seeds. But just be careful with my little wire here. Packages are the way to make modules with a well-defined interface and the main principle is that the user, take it as a library, for example, does not know how it works. And the designer of a library does not know who will use it. So it guarantees the independence of this point of view. So a package has a specification. For example, here I have a color manager and I define a color type as private. It means, OK, I tell you there is a type. It's called color, but I don't tell you how it's made inside. And then you can provide operation. Here we have the redefinition of operation. So I can add two colors to make another color or multiply a certain color by a certain density. I announce those properties, but I don't tell how it's done. There is a problem because the compiler needs to know the implementation if you want to be able to use that abstraction using only the visible part. So a package can have a private part where you tell the truth to the compiler, but the external user cannot make any use of that private part. It's completely checked by the compiler. And then you have a package body that the implementation of the package where you give the actual code for all the provided operations. And an important feature of EDA is that you can use the package as soon as you have compiled the specification. You don't even need to have written the body. So you can write a specification. Then you write the users of the specification. This allows you to check that what you've specified matches the needs of the user. And once you are certain that what you have proposed is what is needed, only then you think about the implementation. So that says a lot of time because too often people write a lot of code just to discover that it's not what was necessary. With EDA you can check it beforehand. And then when you are using one of those packages you must always mention them in a ways clause. So every dependence between modules is explicit in EDA. Which means that you can have automated makers, I should say, without the need of a make file. And so without errors in the make file. That's something I never had a good explanation about. How do you prove that a make file is correct? Well, make files are supposed to have less compilations. Let's face it, every time you use a make file if you have a doubt you say make clean make. Right? That's exactly the opposite goal of a make file which is supposed to save you compilations. But because you don't know well, you could as well recompile everything every time. So the idea is to enforce abstraction by separating specification from implementation. And so as I said, you have no make files. A feature of EDA that you won't find in most languages actually I don't know of any other languages that have that is the possibility of having parameterized types. They are called discriminated types. So the same way as you could define parameters to a subprogram you can define parameters to a type. And you see I can have a component here whose size depend on the parameter or I can even have case parts where the elements that are part of the record depend on the variant of the parameter. So it's very convenient when you have flexible types like here it would be a student record. So we have students may have various majors and if it's in letter they have a gradient late in and so on. So variant record. Ah, object oriented programming. Be careful the model of EDA is somehow different from what you can know from other languages. That's where you see the building work approach. We have seen that packages support encapsulation. There is a special kind of type called tag types that support dynamic binding. A class is a type with dynamic binding which is encapsulated. Therefore it's a design pattern in EDA. It's a tag type within a package. So typically that's not very original. I have a widget so I call my package widget and I give the type that corresponds to the data a special name that's not required by the language it's just a good habit called for example instance. So it's a tag type because you have the word tagged here. And then I can have procedures that work on that. Those procedures that are given in the same package specification as a tag type are what you would call methods in other languages. So presumably you've heard of C++ In C++ you define a class with data members and function members. The function members are the methods. In EDA if you want the package plays the role of the class. The data members are gathered into that tag type and the operations are the methods. So it's not that far away from what happens in C++ except that all the data parts are grouped into the tag type. And then of course you can inherit. So you can define a new type as inheriting from the type above where is my mouse. It's here so you inherit from this one and you can add a visible part or a private part. You may want to give the extra components to leave them visible or to hide them in the private part. So an important feature of EDA is that object oriented programming is not related to pointers. Most languages allow you to do object oriented programming only with pointers. In EDA you can write huge programs including object oriented ones without any pointer. So the whole issue of memory management becomes much simpler. So this model gives you an important difference between EDA and others. Here I have a hierarchy of those types and there is a different type called the class-wide type that includes the whole tree. In EDA we make the difference between a single type called the specific type and the whole tree. Most languages confuse those two notions. And so you can have, for example, if I have a procedure move with a parameter of type widget tick class, it means it can work on every value from the whole tree. The set of value for the class-wide type is the union of all values from each type that's in it. And so you differentiate with that operations method that are on a single type and class-wide operation that operate on the whole tree. And of course if I'm calling that move here, at compile time I don't know which kind of type I have here. Therefore you introduce dynamic binding. So time is running. Starting with 205, there are interfaces that work roughly like Java interfaces. You can define a type as an interface and they can have only abstract or no operation by the way, small improvement. And every operation that claims to implement that type must provide the operation. And you can inherit from one real tag type and as many interfaces as you want like in other languages. As I mentioned, every runtime error results in exceptions and every exception can be handled. So this is the mantra. Once you have taken care of the unexpected, take care of the unexpected, unexpected. At the end of an error program you can have a when other handler that will catch everything that can happen at runtime. Generics, as I mentioned, are algorithms that work on any data type. So you can say that you have a procedure swap and that you have to give it a type. Each private means it has only the properties known to all private types which are assignment and comparison. And therefore for every type that matches a certain number of minimal properties, you can instantiate that generate like this. You can add the compiler to build a procedure swap edge by taking that generic swap and replacing everywhere edge item by edge. But there is a major difference between data generics and C++ templates in that generics are compiled, checked, and provided that the type or other thing that you provide match the requirement then the instantiation is always correct. You don't check at compile time if it's correct. Okay, I hurry. So you have tasking. I'm afraid I was a bit slow. Just a word about the low level. So you have here record. You can specify bit by bit exactly the layout of the record. And therefore if you change a bit you keep the high level approach and you get at assembly level exactly what you want. So the idea of Ada is once again that you specify the high level, the compiler takes care of the low level. Okay, I'll have to skip these ones. I mentioned here are the various annexes and that says that really it's very nice. I often develop on my laptop that is under Windows and I take the code, I recompile, and I put it in operation on my Linux box. I don't even run the checks again because if it works on one side it will work exactly the same on the other side. Okay, we have a good compiler with good error messages. A number of libraries so you can google any library space Ada and you will find that there is an implementation of it for Ada. So in short conclusion you might expect that I tell you use Ada. No, I won't. You are grown up people, you are responsible. I don't have to tell you what you have to do. In conclusion, I just say please, please try. You have three compilers, you have a number of benefits, try it by yourself, and then you can decide if it fits your spirit or your needs or everything that you may require from a language. Okay, questions? Yes? Well, in a sense you could define Ada as an industrial Pascal. Pascal was too small. It was designed to be a pedagogical for universities and it doesn't grow up to be an industrial language. Same thing as you cannot extend a language designed for web to a real-time language. If you see what I mean. Well, associativity is very difficult. There is, for the next revision of the language which is by the way scheduled for next year, there are some reflections about that but it appears to be extremely difficult, especially if you consider associativity of floating points. For example, that's awful. In 2012 you have contracts. So those contracts are checked as runtime. There is a special subset of Ada that allows much more provable thing called Spark. It doesn't cover the whole language but where Ada will check at runtime, Spark will prove at compile time. But of course, in that case, you don't have the full language, not everything provable. Anything else? Okay, fine. Thank you for listening. Now it's time to make the drawing. So please. 141. Who is the lucky winner? You got it. 117. Okay. 117. Here you are. Okay, you're not the beginner. Thank you. So 140. 140. Left already. Too bad. Okay, next one. 155. Okay, with pleasure. And the last one. 156. Okay, you've got something for them.