 this room. I would love to welcome the next speaker, Antonis Christoffides. Hello. Hello. And we can hear you perfectly. Where are you dialing in from? Where I am from, from, sorry. I'm from an island, dialing from Greece. Yes, yes. Okay, so you're self employed. I read your description. And you provide a newsletter. So everybody who likes your talk should go to the schedule and look up your homepage and subscribe. Okay. Thanks a lot. I didn't remember that actually. Okay, so I think you're already prepared to do your talk. So let's share your screen. And I can see the headlines. So the stage is yours. Thanks a lot. So I'm Antonis and I help water engineers bring the models to the web. And essentially my newsletter is about, is for water engineers, essentially. Although some other people might benefit from it. Anyway, those of you who have read the summary of my talk will know that it's actually not about metaclasses. I will get to metaclasses in the end, but it's going to be in the end. So don't watch the entire talk and think, is this guy going to end his introduction at some point? So let's just go. So I have never been in court. But if I ever went in one and they asked me on which book I'd like to swear, I think I would choose this one, you know, the C programming language. It's an emotional choice. I don't program in C anymore. And whenever I do, I don't consult the book. But this is a 30 year old item. It's the only book I keep, although I don't read it. But my focus here is the other book. All right. So if you keep one thing from this talk, it's that you should get that one and read it. I told you I help water engineers bring the models to the web. And an example is this application. So very roughly we measure rainfall and evaporation. And since we know how much water went in the soil and how much went out, we can tell you if you're a farmer, if and how much to irrigate in order to replenish the water that was in the soil. And I told you I'm passionate about clean code. And I'm also passionate about its cousin, good documentation. And this is the documentation for the model we use. Now, this model had a parameter that we used to call the irrigation optimizer. And I had a fight about that with my colleague Nikos, who is the irrigation expert. And I thought I flat out refused to call it the irrigation optimizer because it doesn't optimize anything. I'm sorry I told him this doesn't make any sense. I'm going to call it the Malamos irrigation factor. Until you think of something better. Malamos is his name. And of course, he continued to call it the irrigation optimizer. So for a long time, we use two names. But anyway, just a couple of months ago, he thought of a new name, the refill factor. And that one is quite good because you can think of soil as a liquid container. When it empties, we need to irrigate. And the refill factor tells us how much to refill. If it's one, we fill up. If it's 0.7, we fill 70% of it. So you see, it's not rocket science. But if I tried to explain to you what a parameter is, and called it irrigation optimizer, you would be confused. And that's why clean code starts with good names. For the main part of my talk, I'm going to take you on a tour of bad names. I hope we are going to have some fun. And at the end, we are going to get to meta classes. There are a few that came up while I was watching some talks in the conference, and I remembered them. They're not in my slides, but I wanted to tell you about them. One is a black hole. Now, I'm no astronomer, but I have difficulty understanding this concept at first. Until I understood that it's just a maybe a super dense object. Maybe you could call it a light sucker. I don't know, but it's not a hole. And anytime you have trouble understanding a concept, it's very often because it's named badly. For example, a virtual environment, there's nothing virtual about it. It's an isolated environment. I think this is why many beginners have trouble understanding virtual environments. And there's also virtual host. This is used in Apache. And the same thing in nginx is called a server, but it's not a virtual host and it's not a server. It's just a domain. Anyway, to continue with my slides, let's start with serverless. And the fun with this is that it means the opposite of what it says. If something really does not have a server, you are not going to call it serverless. People will talk about standalone desktop application, for instance. They'll never say a serverless application. If you hear the word serverless, you can bet there's a server somewhere. And my favorite instance of serverless is this post from the Django users mailing list. And you know, I wonder whether the people was intentional. I don't know what a devless server is, but a serverless server, it doesn't make any more sense. Here's another one. Software requirements or functional requirements. There are functional non functional requirements. Many software projects begin with determining the requirements. And they often end up being a deliverable report. And they should really be called feature suggestions, or maybe non binding functional analysis or something. Anyway, I'll need to explain with what yagna means for those who don't know it. The modern way of development is that you have a meeting with the customer once or twice a month, with the purpose of deciding what functionality you are going to develop until the next meeting. Now, in the beginning of the project, it might seem like a good idea, for example, to specify that the results of search queries shall be made downloadable in CSV format. But during the regular meetings with the clients, this might never turn up or there might always be something with higher priority. So you should not develop the feature until the customer presents a problem that they need to solve now. And for which you think that a good solution would be search query results in CSV in this example. This programming principle is called yagany. Always developed something when you need it and not when you foresee that you will need it. If we develop this way, why determine the feature suggestions at all at the beginning of the project, the requirements as they're called. And the answer is that you need to have the idea of where the project is going. Because each feature suggestion, it's a requirement, if you prefer, on its own is yagany. But all feature suggestions together tell a story that helps architect the project as needed. Otherwise, a year later, the customer will request a feature that you can't implement without replacing PostgreSQL with MongoDB, and practically rewriting the whole thing from scratch. So I think that talking a lot with the customer at the beginning of the project and the determining feature suggestions in detail is a good idea. Just don't call them requirements. Because if you do call them requirements, then at the end of the project, some committee or some customer department is inevitably going to ask the question, why has a requirement X not been implemented since it is, well, a requirement? Good luck explaining. That's about requirements. And let's continue with an old time classic. Java script. This is such a bad name that I don't know where to begin. So my sister comes and tells me, hey, Antonis, what computer languages do you speak? And I tell her Python and a little JavaScript. Really, I must connect you to a friend who's desperately looking for someone like you. So she sends me his web page and I see that they desperately want a Java programmer. Good luck explaining to my sister that Java and JavaScript have as much as common in common as an elephant with a cat. I mean, all right, they're both mammals. But if I tell you I have a cat, I won't really expect the discussion to go on like this. And speaking of JavaScript, I have another one. A single page application. So the last time I saw a single page application, it actually had thousands of pages. A few years ago, when a colleague tried to explain to me what a single application is, I had trouble understanding. So you might want to call it a browser rendered application instead or a client rendered application. And that would have been better, but it's still a bit confusing because in the end, all applications are rendered on the client. The difference in a crap is that the HTML is created on the client. And even this definition falls apart when you add server side rendering to the picture. So if you can't find a better name, what you can do is call it Alice or Bob, Charlie, David, whatever. When it's hard to find a term that is descriptive enough, it's better to choose something irrelevant like Python, for example, than to choose a confusing description. And besides, that's why I had used malamos irrigation factor before we found the better refilled factor. In fact, I've done this with a class of statistical models and I've given them the name George because I can't think of a better name. George has this form. Don't try to understand the math right now. The important thing is that it has inputs, outputs and parameters. And you typically determine the parameters by calibrating George using known inputs and known outputs. Nowadays, many people use the word training instead of calibration. And they also use machine learning for the process of creating and calibrating models like George. And in fact, I am the only person I know who calls George George. Everyone else calls it neural networks. And as you can understand, I think it's a bad choice because it suffers from two problems. It's not neural. And it's not a network. It's pretty much like this musical instrument, which is called the English horn, when actually it's a French oboe. Anyway, the discussion about neural networks brings me to artificial intelligence. What is artificial intelligence? Some people think it is the attempt to create a machine that thinks like a human. And this definition does have problems. What does it mean to think like a human? But I can accept it for a moment. The thing is, you don't need to be particularly intelligent to walk on two legs, do you? Humans do it from the age of one. Hens and ostriches also do it quite successfully. If AI is about thinking like a human, why does it also study walking on two legs? And there are other people who think that AI is about using models that incorporate probability. And I think that's a good definition. The other time I went to my wife and said, I found an old picture of yours from the trip to Spetsis. Spetsis is a Greek island. And she tells me, not only did I not come on that trip, I've actually never been in Spetsis. I said, OK, I found many photos or maybe I'm confusing places. So I get the photo and I check it. And there was a group of people in Spetsis. And this girl isn't me, she said. She looks very much like me, but she isn't me. And so I recognized my wife on a picture, but it wasn't my wife. I can recognize her face with a probability of well over 99 percent, but it's still less than 100 percent. It's not like adding two and two. So image recognition, walking on two legs, natural language processing and many other problems have an amount of uncertainty in the results. But in this case, we should not use them as leading AI. We should be using probability modeling. The other time I found an article about Pacman and the guy went on to explain how the ghost's AI works. But there is nothing uncertain about how these ghosts move. They confuse you when you're playing because the algorithms of their movement are ingenious, but they are very simple. So for example, here, the orange ghost is going up and it has to make a decision of either it will go up or it will turn right. So what it is going to do is it will follow the route that takes its closest to its target. Its target, if it's away from you, as in this case, its target is you. So it's going to turn right in this case. But if it's nearer to you than eight tiles, then its target is the lower left corner of the screen. So there are some more details. And each ghost has a slightly different target or algorithm. But essentially it's as real. It's as simple as that. So how does this how does this person define AI? Is it an algorithm? Is it any algorithm that can surprise you or any algorithm used for an autonomous character in a game? The problem is that if you use such a vague term as artificial intelligence, anyone can think you're meaning anything. And let's come to the European Union's proposed definition of AI. Last April, the European Commission published a proposal for an artificial intelligence act. And it has provisions such as prohibiting an AI system that deploys subliminal techniques beyond a person's consciousness in order to materially distort a person's behavior in a manner that causes or is likely to cause that person or another person physical or psychological harm. In the directive, the definition of an AI system is essentially any system developed with any one of these techniques. And what interests me most here is the third technique. I generally agree with the European Commission. I think that AI is models that incorporate probability. Now countless hours have been spent in order to prepare this European proposal and hundreds of members of parliament, thousands of assistants are going to review it, discuss it, review it again and then the council is going to review it and then the commission again, maybe the parliament again. And anyway, tens of millions of euros will be spent. And if it passes and becomes law, is it going to be useful? If you cause a person physical or psychological harm, isn't that illegal already? Why does it matter if you used statistics to do so? None of this would have happened if we used probability modeling instead of AI. This is how damaging misleading terminology can be. So let's now come to metaclasses. The official documentation says that a metaclass is the class of a class. What? What does this mean? I mean, crookshanks is a cat and the class of crookshanks is cat. Cat is a class. So the class of a class is class, maybe. Does this make sense? Or could it be that, you know, I like to think that cat is 42, because some people think that 42 is the answer to everything. And let's try it on the Python interpreter. If you try this on the Python interpreter, you're going to get a narrow int object is not callable. And that's interesting. So if we do try a callable, then it works. But can we try to create an object with it? And we get a narrow again. So I could continue exploring it and make it work somehow, but I promise it's not going to make any sense at all as long as you think of it in terms of classes of classes. And given what I've been presenting until now, I think you guess where this is going. There's no such thing as a metaclass. The concept actually has as much to do with classes of classes as English horns have to do with England and horns. The correct term, I think, would be class creators. And in order to make this absolutely clear, I downloaded the Python source code and replaced every instance of metaclass with class creator. And it's compiled. So I hope this is now making more sense. In fact, I think it's easy to understand it. A class creator is a callable that creates and returns a class. So for example, this class creator adds the 42 attribute to the class it creates. It starts by calling type. Type is a built-in that creates classes. In fact, it's the default class creator. Now, this particular example isn't useful. And in fact, I think you should avoid using custom class creators without good reason, because they would make your program unusual. But sometimes class creators are useful. For example, in Django, when you create a model such as cat, then cat dot does not exist is also created automatically. It's the custom class creator of the model that does this. And it does many other things as well. So you will use class creators when you are developing low-level stuff like Django, and you want to do some magic. And that's all there is to it really. This is my last slide. I have nothing more to add. All you need in order to understand metaclasses is to mentally replace the term with class creator. That's it. Thanks for watching. Hey, I'm back. Thank you very much for the I was expecting that loss, but we'll we'll get one for you later. Thanks very much for doing this presentation. And we we had some activity in the question and answer room. And it's more like comments. For example, when you showed the two books, we got something from Diego. He said, I've got both of them. So he was really happy. So you made a good choice there. And there was also a comment on black holes. David meant that the intent of calling the black hole is just to make you think what a hole means. And what he says he's a physicist. So he might be biased to that. Yeah, I am I said I'm not an astronomer. I've I've read a bit. I'm a little bit of an amateur astronomer. And well, of course, of course, I'm passionate about being accurate. So black hole confused me. And I think a beginner might be confused. In some cases, when you become an expert, so to speak, you, you come to understand the term, such as in virtual environments. First, you are confused. Then you come to understand it. But with difficulty. Sometimes I think the the bad things that the term means stay with you for a long time. And so you, you have probably noticed that I'm very skeptical about artificial intelligence, for example. Yeah, so you could have used finger quotes or so called artificial intelligence, which would also have worked fine. Yeah, I always do this. So when I write articles, I have, I say probability modeling. And in brackets, I say also called artificial intelligence by some people. Yeah. Anyway, we, we enjoyed this a lot. So thanks very much. And I think we found your applause. So let's let's play it.