 Okay, so rapid application development and data, not a combination you hear about and most likely most people would call me crazy for saying it's possible. In essence, building things as quickly as possible. It's not always a nice solution to the problem, but sometimes you just need a solution and you don't really care about elegance. For disclosure, I'm still finding out ways to do certain things, because I sometimes just have to find a way to abuse some language features to achieve the goal. So still work in progress, we could say, there are many more possibilities to be found. Typically you will find that people use JavaScript, Python or Rabia as recommendation for that, which is all fine and well, except why are they used? Libraries. They have a lot of libraries to support many things. We don't really have that many libraries because we don't have that many programmers in Ada. Without libraries, we don't have programmers. Without programmers, we don't have libraries. It's cut through too. Somehow it has to be solved the problem, so got to create libraries first, I suppose. Alire is going to help with this because at least they are going to be more visible and easier to find. And another thing is that the Alphorn disclaims all warranties. That's standard in most EULAs and licenses. As to say, it doesn't matter the quality of the software, there is pretty much no liability for it failing. And the result is the internet of threats and buggy applications. Does anyone actually manage to properly sue and win the case against some company developing software? Sometimes, very rarely, when they go way overboard with how broken the stuff is delivered. Kind of after decades of court cases and did they go to court actually? Not yet? Yes, for the next couple of decades and the court case will take another decade or two. And by that point, it no longer matters. So it's not really nice and that's actually why they use programming languages that don't help with solving or rather creating proper software because if you have no liability, you can use anything at all. And that's mainly with all these languages that are supposed to be nice for rapid application development. Because there is only time to deliver as metric, but actually if you look into this stuff, what happens is that they either rewrite the software constantly. We have, I suppose everyone has seen this happen. And two, backfixing and maintenance is often just ignored as costs. It's just cost is to deliver and everything else, it doesn't matter. It's not a proper and nice way things are done and not how it should be done. And I also have two of them experienced bugs due to release of just a prototype into production. Because as we all know, it's just a prototype and when it goes delivered into production systems, even from banks. I had my share of issues with banks delivering software that's not ready to use. Why not AIDA? Yes, we don't have library supporting crowd. It's one thing to have library that does something and another one that's very easy to use and very quick to the goal, to achieve a goal. Yes, while the goals are similar, it's actually interface that matters. It's all about interface. And our standard library in AIDA is quite good, but we do have some craziness that I like, for example, AIDA calendar and AIDA calendar formatting, which as anyone that has used it, but one probably not he said, but he also uses the other one at the same time. So we end up with two packages instead of one. Not to mention other things like, for example, unbounded strings, not having indexing or iterators defined. So we cannot do four off on unbounded string for indexing is because unbounded string is not target type. Main advantage of AIDA is proper abstractions. We can abstract things, and that means that we can hide things, the ugly details that are needed to achieve goals fast. In Python, for example, there is a convention how to do private stuff. Convention underscore in the name is a convention. It's not a check it if you can still access private parts of anything really. And that's software running production almost everywhere, almost. And strong typing system means that many errors that are bound to happen are discovered early, and that of course means that whatever we achieve, if it compiles, it's likely to work, and that means that we no longer have to debug it and to force to work actually because time to deliver just having a small prototype that just really works and having something that actually works are two different things. And we can then focus on another product, of course. And also value-based type system, because anyone experienced issues with type conversions in C or other type casting, I suppose, a very one, right? I guess you only change what you see actually. Bits are the same, values change, but nothing is preserved. It's nice in Aida because when you have some type that has certain range, and you try to convert this value to, say, modular type, if that range is negative in the first type, value is negative, then you will get exception. And in C, you will just get something. I am not sure what. That's something. And it's often repeated in many languages, the same kind of issue in JavaScript, implicit conversions in Python, I suppose, as well, everywhere pretty much. And useful stuff for rapid application development I find the most abusable is target types, actually. Not for inheritance, really, because I don't find inheritance to be the best solution to most of the issues. It's actually kind of backwards. At the documentation for primitive operations means that you don't mess up arguments. And that's if anyone has, you said, Aida text IO, end of file, for example, anyone probably has at some point forgot to pass argument. And then you end up with a program hanging in an endless loop because you forgot to pass argument. That's my experience, at least it happens at times. Extra stuff locked behind target types, like, for example, user-defined indexing. It's kind of handy and actually very useful for certain types and structures. Relatively common loop. I think anyone has seen this kind of loop or written it at least once. Standard, just read the file. But you can do something like this as well. You can actually define iterator for a wrapper around text file. And you can actually loop over text file getting line at a time. Kind of a hack, but it's really important is not what this example does, but what is the limit of how you can push this thing. Because it's one thing to read a text file like this, I suppose. One thing to read text file like this. Another thing to, for example, iterate over, say, unbounded string and getting word at a time. Or maybe a field if you have field separator, like CSV files, for example. It's imagination is important here. How far we can push it? And can we push it quite far, actually? I don't know how far I could push it, but I have not written the limit yet. And when there is user defined indexing, it's very handy. Unbounded string doesn't have user defined indexing because you need type for it. But if you have certain types, like, for example, vectors. Or unbounded string, for example, which is basically a vector of characters. You would want to access elements of this vector or of the structure just using index, not going through special procedures and calls and writing even more code, but basically means the same thing, but it's harder to understand what's happening. Then some map cut. It's a pretty much example from standard, actually. Where you have example where you can access, this is actually also indexing. Because indexing takes two parameters, one parameter and a data structure itself. So we can index by pretty much anything. How far can you go with this? I don't know. Does anyone know how many, how much automation can be done with this? In the event of a day, it's all about what we can implement inside libraries as interface, so what we can do things easily. And contracts, low and behold, they're actually very useful for rapid application development because you can document for one thing, you can document ahead of time as a spec. What's your expect as input? Here is a bug, actually, whatever. And you can actually check with post condition if what you get is what you expect to get. So it actually kind of manages to work around the need for as much testing because you don't need as much testing, and it really helps. The less you have to test, the faster you can develop, just like this. And coming soon is global aspect which I find to be very nice, at least in my personal experience because we often write some procedure, and this procedure itself may be just nice procedure that doesn't access any global state. But inside this procedure we have inner procedure, and suddenly it accesses various variables declared inside this procedure, so something like this. We have XYZ declared inside process, but auxiliary procedure is accessing variables, and without global parameter, global aspect, we cannot check if document what this is happening actually. And what happens is that at some point in time, you notice that actually you want this procedure to be outside of this scope because it's useful in other places. And so then you have to go one after another after global states handling, and that can be quite mind boggling and time consuming at times. So documenting which global states we use and how is actually very useful. Any questions so far? I guess I am not afraid of questions. And other stuff coming with Aida 2020 as well. Data aggregates will be very handy because we all at some point had very big data structures, with big records, with many fields. If you just want to change one field, I mean you make a copy of a record, and then you want to change just one field, just that one field, well you can make it with data aggregates and it's much faster to write. Much easier to understand as well. You can also work with arrays, so it's very nice. Procedural iterators, it's kind of, actually it's going to be useful as well. But it's, you only have in various aspects in standard Aida library, we have many types and packages that have this iterator process procedure. So instead of writing a procedure and then passing a pointer of this procedure to actually process because it takes action, procedure as a parameter, we can actually write a loop and loop over entire data structure and with custom procedure actually without writing. It kind of like lambdas in many languages, kind of container aggregates, that's going to be useful as well, but also kind of hard to implement at times I suppose. User defined thick image, it's something that was requested for a while and for a long time. And I suppose the very one at some point wanted, or actually I suppose almost the very one writes image procedure or equivalent to write a string representation of a type. Because it's useful for debugging, for quick checking what's going on. Why not give a thick image properly? User defined a lot. Reduction expressions like map or reduce and parallel blocks, which are going to make writing parallel software much faster. I suppose a very one had something like this at one point in time. And yeah, small advice, GPS help many. There is actually a lot of stuff inside Gnat runtime, a lot of stuff that people don't realize just what is there, like for example speedball stuff or the various sorting algorithms, various key sort implementations. And also we have three XMLAIDA and documentation and probably some more, AWS as well, it's kind of short presentation questions. I have one question to everyone, because you see when it comes to writing a library to support rapid application development, a very one has its own scratch to each to scratch. Everyone assumes that what they do is what everyone does. That's not really the case. And what I want to do is not exactly what you may want to do. And what I'm asking for is for input as to what people want to be done so that such library could be written. And without the input, it's kind of hard to do. I know what I want to do. I don't know what you want to do. Okay, any questions so far? No questions at all? Not even how far I have pushed iterators because you can rewrite it, yes. That's why you say that a lot. Yes. And that's why I would like to use Ada and enable more people to do it because people like me or you, for example, we know Ada quite well. We know Ada so well that we actually can do many things that seem impossible at first. But it's different story when someone doesn't know Ada by heart mostly. I know. So I hope I won't be called at Thomas' pathology with iterator over text files and other things like this. Yes, we actually have UTF string in Ada. That's true. UTF-8 handling in Ada is not trivial, but well, it depends how you are going to handle the string because handling the strings and then actually graphems and all possible combinations of what can happen with it is not that trivial. If you just treat it as a series of code points, then you could write a library that does just that and handles only UTF-8 or whatever unicode version you prefer. I suppose that's something that should be done actually. So what G-Leap and GTK Ada as part of what? Okay. Yes. Many people are confusing character set and encoding with a totally different issue. UTF-8 is just an encoding. Any other questions? Thank you very much. You're welcome. Thank you very much.