Yehonathan Sharvit: 0:00

In the same way then that when you add the two, a number, let's say 42, you have two, then you get 44, but you don't mutate 42 42 stays 42 in Data Oriented programming, the same thing happened with objects or hash maps. If you have a hash maps with two keys, two fields, and you want to add. You don't mutate the original map you create a new one. And if you adere to that, if you separate codes from data

Fernando Doglio: 0:42

You're listening to episode number eight of 20 minute JavaScript this episode, as all others is hosted by OpenReplay an open source session replay tool for front end developers. If you're looking for a way to understand how your users interact with your application checkout OpenReplay. I'm Fernando Doglio, your host, and the voice in the back of your mind, at least for the next 20 minutes. And in today's episode, we're going to be talking about data oriented programming. What is it? Why should you care about it? Two very good questions. And to answer them, I have with me Yahonathan Sharvit software architect and author of data oriented programming. So Yehonathan welcome. Thank you for being here and please introduce yourself.

Yehonathan Sharvit: 1:21

Okay. Uh, first of all, thank you, Fernando, for inviting me to your show. It's a pleasure to be with you. Um, my name is Yehonathan. I live in Israel in a small village. But as you may hear, uh, in my accent, I was born in France. I have a high, strong accent, and, uh, I, I, I, I have lived in Israel since I am a 17. So I learned at school here and I work. I have worked only in Israel as a software engineer. Uh, Maybe the most interesting, interesting thing I can say about my career is that there is definitely a turning point at 10 years ago. And this turning point happened when I discovered closure before closure, uh, programming was just my job. And since closure it has become my passion. Um, so for the, you, are you familiar with.

Fernando Doglio: 2:26

I am a bit, I had played around with it, nothing professional though.

Yehonathan Sharvit: 2:31

Okay. So there is closure and closure script .Closure, uh, gets transpiled to Java and it runs to Java bytecode and it runs on the JVM on the server side and closure script gets transpiled to JavaScript. Another language that gets transpiled to JavaScript, and it's not a very popular language. It's kind of a niche language, mostly because of. The lack of a big company behind it. Um, and also the, the syntax that is a bit scary, you know, the list syntax with the wierd parenthesis.

Fernando Doglio: 3:07

Yeah.

Yehonathan Sharvit: 3:09

But once you, you, you get used to it. It's such a rewarding language. It's, it's difficult to start, but once you start, you learn so much from the language you become a better programmer. As you, you master the language more and more, and you, you become a better programmer not only as a closure programmer, but you become a better programmer in general. So since I've discovered closure 10 years ago, I've been developing mostly in closure, but also in Ruby and JavaScript. And, and the way I code in JavaScript today is different than the way I used to code in JavaScript 10 years ago. And I think it's a better way. And that was the, the. The driving force being behind my, uh, willing to write a book about not closure, but about the philosophy of closure or to be more precise, the closure approach to data. And this is what I call that oriented programming.

Fernando Doglio: 4:09

All right. Yeah. I was going to ask you if closure had anything to do with data oriented programming. Interesting. Okay. I definitely agree with you. Looking into different ways of coding, different languages, especially if there's follow such a different, uh, paradigm than the one you normally use. Uh, it's a eye-opener because even if you're not going to be using it on your day to day, it will give you different ways of solving the same problems. So, absolutely agree with that. All right. So after that intro, uh, tell us finally, what is data oriented programming?

Yehonathan Sharvit: 4:46

Yeah. So first of all, I, I need to say that I think JavaScript is almost a data data oriented programming language. And I am going to explain why I think one of the, the greatest contribution to the world that Brendan Eich ma made when he invented JavaScript is the data literals. And the fact that in JavaScript since 1995, since the beginning, it's so easy to create data to manipulate data. And that's a huge, huge, that makes a huge difference. Think about, I don't know, Java or C sharp or language like that, popular languages. If you want to create a hash map, it's a headache. You have to declare the type of the keys, the type of values to have the generics, to have the constructor. And when you want to manipulate everything is painful. And in JavaScript, it's so simple. You have the curly braces and the square bracket. If you want to have a vector and boom, you have, you have data and it's just data. Um, so that's one of the greatest contributions. And I think it's one of the reasons why JavaScript become so popular because when you, when you write a front end application and after that, even, you know, node in the backend, basically what you do is data manipulation. So JavaScript is almost data oriented programming language. And why do I say almost? For several reasons. First of all, because in JavaScript you can do, you can have objects where you mix code and data, and this is not aligned with data oriented programming, in data oriented programming you want to separate between code and data. And the second reason is that in data oriented programming, we want to treat data as a value and more precisely as an immutable value. So we don't allow mutations. You can, if you have an object, a you cannot say,"a.b = 2" . It's forbidden in the same way, then that when you add the two, a number, let's say 42, you add two. Then you get 44, but you don't mutate 42 42 stays 42 in data oriented programming. The same thing happened with objects or hash maps. If you have a hash maps with two keys, two fields, and you want to add a third field. You don't mutate the original map. You create a new one. And if you adere to that, if you separate codes from data, if you were present that, uh, as generic data like in JavaScript, and if you don't mutate the data, then you are, uh, applying data oriented programming principles.

Fernando Doglio: 7:23

Interesting. Okay. So data on one site code on the other, that's the philosophy.

Yehonathan Sharvit: 7:29

Yes. And that, data has a value data as a value, right? Yes, immutable.

Fernando Doglio: 7:36

Okay. And is this the same as data oriented design? Because I've been, I've been trying to research a bit about the topic and the both, both terms came up. So yeah.

Yehonathan Sharvit: 7:47

Yeah, no, no, it's not. It's unfortunate, but you know, naming is hard and, uh, it's not just, data oriented design is about, is about optimizing performance and data oriented programming is about. Reducing complexity system complexity. It makes your code easier to read and to maintain and to debug, et cetera. It doesn't make your code run faster.

Fernando Doglio: 8:13

Okay. And from what I've been reading, uh, in your book and a bit online, uh, from what I understand is, you shape your data based on your, uh, business requirements. Right. And then write the code to, to deal with it. Would you say that that is a better approach that letting the business requirement shape your, your logic essentially, and then that logic uh, shape whatever data you need essentially bottom up versus a top down approach?

Yehonathan Sharvit: 8:49

Yeah, I would say that the business logic and the business domain shapes the way you represent data, uh, that's the first thing, but then you implement your business logic rules as data manipulation functions, generic general purpose functions like filter or map reduce group-by, et cetera, right there. And even custom logic. Usually we are able to express most of it as generic general proposal data manipulation functions. And why is it important? It's important because it makes the code less buggy and easier to test it's much easier to test a general proposed data manipulation function than a business rule, a function that is, uh, interleaved with the business domain. And quite often in that other programming, we are able to express complex business logic rules. Just as data manipulation, uh, facts or constraints, and that's highly beneficial. And I wanted to add the fact that the data never changes. It also gives a strong guarantee that when you call a function, you are guaranteed, that the data you pass is the data. It will not be changed by the function. The function usually returns a new version of the data or calculation of the data, and then the whole problem of, uh, thread safety that maybe it's not so important in JavaScript but concurrency management or passing by reference passing by value, uh, defensive copy, defensive, cloning, all of that is this whole family of bags simply does not occur. And it's also quite fun.

Fernando Doglio: 10:43

Hmm. Uh, okay. So, so far, let me recap, uh, summarize here. You talked about immutable data. You talked about general purpose functions, uh, and data manipulation manipulations. So how are we not talking about functional programming essentially? What's, what's the difference between functional programming and data oriented programming? They seem very similar.

Yehonathan Sharvit: 11:05

Yeah, that's a great question. So, first of all, What they have in common is that we separate code from data. Secondly, data is immutable, but usually in functional programming, usually when we say functional programming, we mean Haskell, oCaml F#, all this stuff. And we, with all these family functions, we spend lots of time typing our data. And data is not generic. We don't represent business entities as hash maps, represent business entities as custom types. And that's not the case in data oriented programming. So if we take functional programming and you remove types, you get data oriented programming.

Fernando Doglio: 11:53

Okay.

Yehonathan Sharvit: 11:54

And it makes, it makes it, it makes, it seems like a small thing, not to type, but it makes a huge, huge difference. And also in functional programming. We don't emphasize it so much. The importance of immutable generic data structure we clone, or we do custom tricks to create a new version of data in data oriented programming, we leverage a smart data structure called persistent data structures that are, uh, efficient. So when you create a new version of the hash map, let's say with a 10 fields, you don't clone the hash map. There is a way, a smart way to, in a sense, cut the cake and have it too you create a new version without creating a new version. So we have two different versions separated, but the data that is common is shared and because it's immutable, it's safe to share. And that's usually not the case in when we say functional programming in the traditional way, the traditional sense.

Fernando Doglio: 13:02

All right. And you have that, uh, smart storage, um, implemented in JavaScript?.

Yehonathan Sharvit: 13:09

Yes. You have it in every language nowadays. It, it was one of the most important contribution of closure when it was a launch in 2009 back then there were no persistent data structure, efficient persistent data . Structure and Richie, the inventor of closure, the inventor of closures. Spent lot of time to find the appropriate data structure. And he found one, he didn't invent it. He found one called H A M T hash array map tries. And it's the underlying data structure of native closure data types. But then since then it has been ported for first to Scala and then to JavaScript in a library that used to be maintained by Facebook called ImmutableJS. And in Java and in Ruby and in C sharp and in Python, and in every language into, in 2022, it's available in, I think that even in C plus plus there is an implementation of a persistent data structure. And also let me mention something for the JavaScript community. There is an approach, an approximation of that, of persistent data structures provided by lodash. And ELM and Rambda. So they do a trick that naive. I call it a naive structural sharing that makes it possible to manipulate regular JavaScript maps as in an immutable way. And it's almost as efficient as the rig, as the persistent data structure for that. You need to use not the regular lodash, but the lodash FP. And for example, with lodash FP, when you call set on the hash map with the, with the key and the value, you don't mutate the map, you receive the new map that has in common, all the fields that have not changed. And ELM also the does the same trick and Rambda the also, but it's naive, structural sharing. It works until you have too many elements in your collections. Let's say if you have more than a thousand elements, you, you might have a performance issue, but if you have less than a thousand element, it's fine. So when I work on the JavaScript project, this is, this is the, the, the trick I use I don't bring a non-native data structure from immutable JS, because usually I don't have more than a thousand elements in the collection in memory, whether I did the front end or in the back end, I don't have so many elements. So usually it's fine. That's the simplest way to get started with the data oriented programming for JavaScript folks to learn to embrace lodash FP, ELM or Rambda.

Fernando Doglio: 15:59

Cool. And on that topic on the book you mentioned that one of the key functionalities, one of the key traits of object oriented programming is inheritance. And, uh, you see you, you propose the problem of how do we deal with inheritance when. We don't have objects. We don't have classes. Um, you talk about the multi method. Can you describe that? Because if it's a very, uh, interesting solution that I've never really heard about until after your book. So, uh, can you tell our audience what is a multi method and how do you use it, especially related to the DOP?

Yehonathan Sharvit: 16:36

So this comes directly from functional programming. It has nothing to do with data oriented programming. And it's a way, uh, I discovered 10 years ago for me until 10 years ago, I thought that polymorphism was a synonym of inheritance, you know, to be able to, to have a function or an object behave differently based on the dynamic, uh, type of the object. I thought it was the only way to achieve that was through objects and inheritance. And 10 years ago, I discovered this concept of multi method that is a built-in in Closure. Where, you could say I have a function and I have multiple implementation of the function. So for example, uh, let's say the classic example of an animal that cries, right? So you have a basic implementation for "cry", and then you have an implementation for cat and for dog and for cow and for horse, et cetera. And there is a way to say, okay, I'm going to look at the argument I received and based on some logic on the argument, I'm going to dispatch the appropriate function. So for example, let's say you represent an animal as a hash map, where there is a key called type or animal type, and the value could be horse dog. You could write a dispatcher function that checks the type value of the animal and based on the value, it dispatches to the appropriate function called, and it gives you the, the same thing as inheritance without the need to have objects. And there are packages in G, so it's not available, uh, natively JavaScript, but there are packages that, that I mentioned in the book that, uh, provided. Uh, implementation of multi-methods. It's not a lot of code it's, I don't know dozens of lines of code, but it makes it easy to leverage a polymorphism. And sometimes it's important to have a polymorphism. And, um, I don't know why it is not because it's simpler than inheritance and it's more powerful than inheritance because you could have the dispatch logic based on two arguments, not only on the first argument. So for example, you could say, uh, if the, the type of the animal is dog and the name of the dog is more than five letters, you're going to dispatch to another function. If you have something like that, and you cannot really do that in a classical object every time. So it's more powerful, it's simpler, but for some reason, Let's popular.

Fernando Doglio: 19:13

Absolutely. I think that is the curse of functional programming, right? I mean, up, for some reason object oriented programming is way more popular. So we all tend to think in objects, at least that's the way we are. We're thought to start at the start of our careers, anyway, many, many of us eventually discover functional programming. And are like you.

Yehonathan Sharvit: 19:34

Th there is a great quote by Alan Perlis is about that. So it's, simplicity, simplicity, never preceeds complexity. Simplicity always follows complexity. So first we find the solutions that are complex, we use them and then we're able to distill and to simplify, and then we find a simpler solution. But the problem is that there's complex solutions that already widespread. Always too late in a sense.

Fernando Doglio: 20:06

It's true. That's true. But, uh, yeah, I love that quote. I'm I'm actually going to steal it because it's very good. It makes a lot of sense. Okay. One thing that I've not been able to really understand about DOP is. If we've been talking so far, uh, and, and I understood until now we split data one side and logic and code on the other. You have a very interesting diagram, your book about that. Showing that that's split when you create a data and generics and validation and all that is split from the actual logic. But if you do end up having an, you know, a real world application would have, uh, complex data structures, right? Uh, your function. that are meant to be generic will have to know anyway, the internal structure of that data so that they can use it because there is no really functionality associated to the data. So doesn't that couple, the actual data to the implementation, to the point where they're not really different from, uh, or they can't really exist individually. Uh isn't that kind of what Object Oriented Programming ends up being?

Yehonathan Sharvit: 21:19

Yeah, so that's a great question. And let me first tackle the easy part. So first of all, you have functions that don't care about. They done the structure of the data. For example, the function that let's say. Counts the number of fields in the hash map, you could pass any hash map and the function works, you could think about even more advanced function, like a function that rename keys. You could have a function that receive a map and a field named transformation. And in order to implement this function, you don't need any knowledge, but they don't have structure of the data. And you have lots of functions like that. And in object oriented programming, you cannot write functions like that because you always have to know the exact type of the fields. You cannot write, uh, an object method that renames fields it's impossible. It makes no sense. Or you would have to use reflection or very complicated thing. While when you separate data from code, it's trivial. And many of the lodash set of functions are advanced functions like that, that are pretty hard to implement and impulsive in a DOP and impossible to implement in OOP. So that's, that was the easy answer now to the difficult answer, let's take an example. Very simple example. Let's say you want to write a function that calculates the full name of an author. Okay. Let's say we are in a library system and we are, we have books and authors and users and members, et cetera. And let's say we represent an author as a map with the first name field and the full and the last name field. And we want to write a function that returns the concatenation of the first name and the last name, nicely capitalized with the space. So now you cannot write this function as a generic function. You need to know what's the name of the field? Is it first name? Is it the first name is the F lowercase uppercase. So you need this information, um, on the one hand. Yes. But on the other hand, you could, once you have written the function, you could pass to the function, not only authors, but you could pass also users. If the user is represented as a map. With first name and last name and many other fields, email, and the number of books, et cetera, the function that calculate the full name doesn't care. So that's the power of data oriented programming. It only cares that about that. Some fields need to be there. It does not care about the whole, it's not limited to a type of maps. It works with all maps, where the keys, the fields, first name, and last name are there and there are strings and that makes a huge difference. First of all, in terms of reusage capability. And secondly, in terms of testing, if you want to test the function, uh, full name, you don't need to know about authors. You don't need to import the class definition of an author. You just need to create a map with a first name and the last name and in the real life, when the application runs the map that gets passed to the function full name may have dozens of other fields and you don't care. You don't have while in OOP if you had a function like that, you would have to create a real author object or a real user object with all the fields, just to test a function that cares about two fields. There is, uh, an idiom that goes, and it's a bit demagogic, but it says that in OOP usually in order to test a tiny function. You need to build your whole system wide in data oriented programming. If you, if you need to test the function that checks the first time and the last time you only need to pass the first time and the last name as a map.

Fernando Doglio: 25:14

I see. And I see why you say that JavaScript is so good at DOP. We got that. That's definitely something that you wouldn't really think twice doing it in JavaScript.

Yehonathan Sharvit: 25:22

And by the way we have the complimentary problem is that sometimes our code is so dynamic and so flexible that we don't know what we have in hand. So for example, if I, uh, go back to the full name function that calculate the full name of an author or a user, there is no clear way, but by just looking at the function signature to know what is the expected shape of the data, you have to read the code to discover that first name needs to be written like that. And there are three ways to deal with that. First of all, to say, okay, that's a problem that the first way, the second way is to document the function and somewhere to write, these function expects a piece of data, having a field called first name in the field called last name. And the third is to leverage, to type "a la carte". So you could use a language like TypeScript and type this function, full name and say. The data pass here should be, uh, should be compliant with an interface that has a first name and the last name and both of the fields need to be string, or you could leverage a technology like JSON schema, where you would specify the schema of the data somewhere and just say, write a piece of code that validates that at run time. Whereas in TypeScript is at compile time that validated the data is compliant to the expected schema.

Fernando Doglio: 26:45

Okay. Yeah, absolutely. If you don't want to go to the TypeScript way then JSON schema, and I think you use that in your book as well. That example is the way to go.

Yehonathan Sharvit: 26:54

About yeah. And the important thing, no matter if you JSON schema or TypeScript. The important thing is that it's "a la carte". And for example, if you write a function, renamed keys or count fields there, you don't need to types because there it works with any data. So it's, again, it gives you much much more flexibility than the traditional, a statically typed approach, where you have to type every single piece of code, or sometime you just want to prototype. And you just want to experiment with code. You don't want to waste time on typing. So. It's the responsibility of the developer to decide what to type and what not to type. And sometimes it's a problem because as another idiom goes with great power comes great responsibility.

Fernando Doglio: 27:41

I know that one. Okay. Awesome. Final question about DOP.. Would you recommend it for any use case or have you found a use case where, or type of projects or type of platforms of software, any way that you've tried to build with DOP that you said, well, this is definitely not the best way to go about it?

Yehonathan Sharvit: 28:02

I don't think it's a solution for everything. I think it's a good fit for information systems, for systems that manipulate data that comes from the outside. For example, a backend application, the data does not come from the application. Usually it comes from that from a database or from a message queues or from a rest API or from it comes from the outside or a front end application that receives data from the backend. But if you build a compiler or if build a game engine, And you generate, you create the data about. The AST abstract syntax tree of the code or about the mechanics of the game engine. And you have no surprise, you create the data that you consumed, then it makes it makes more sense to use another, uh, paradigm, uh, where you don't need as much flexibility as we need when we build the information systems.

Fernando Doglio: 28:58

Okay. Finally, can you, uh, tell the audience a bit more about the book and what's in it and what they will get out of it?

Yehonathan Sharvit: 29:07

So, first of all, let me tell you something, uh, that you have probably noticed. And I'm curious to know if you appreciated it or not. The book is written as a story.

Fernando Doglio: 29:15

Yeah. I saw that. Yeah. Yeah, it's at first it was interesting. I had to like adjust to, to the way it was written because I couldn't just pinpoint the specific topic I wanted to, uh, I wanted to, to, you know, to read about, but at the same time, since this was a completely new topic for me. Reading the whole dialogue between these two characters, uh, helped me ease into the topic and understand, you know, what you, uh, the reasoning behind it and, and kind of what you want it to, to explain. And the, the counter examples that you gave. So it was, uh, I never seen a book, a technical written like that. So it was, it was interesting.

Yehonathan Sharvit: 30:01

And the reason I wrote in this way is because, uh, my tendency is to be overenthusiastic. And I would say that at first, data oriented programming is the best thing in the world. And it has no issues, no compromise, no trade off. It's the best for every project, et cetera. And of course it's not true. And the way I found to be more, uh, honest was to imagine. That I will say that to someone. What, what question and what objection this person would ask. And I started to play this game, this mind game between me and myself. And then I say, why not just writing it this way and writing the dialogue and the questions and the argument and yes. but or why. And, and, um, so I liked the game and I played it until the end. And then I made also little story with the background and then drama. Of the character. Then there is the leader of drama. And so, so that's one thing, uh, that I can say about the book. Another thing is that it's very, very pragmatic. It contains lots of, uh, JavaScript code snippets. So no idea is left in the abstract land. Everything is down to earth in the, the applicable and I, because that's the way I learn. It's very hard for me as a learner to, to digest abstract stuff, the simplest way, or the most efficient way for me to learn stuff is to see the code that implements the ideas. So I thought that I would need to give that to my readers. And it's also build slowly by slowly. It's like a journey. It's like an initiation journey from the regular paradigm, like OOP or statically typed language slowly by slowly moving step after step into. Uh, data oriented programming. So that's, that's how the book is written.

Fernando Doglio: 31:57

Yeah. Yeah. Uh, it's really fun to read and it's, it's easy to understand the topic, so definitely recommend it. And we're going to have a discount code for our readers on the show notes so they can pick it up with an interest in discount. Thanks to Manning for that. Um, okay. So. Enough of DOP. I'll have three more questions that we ask all our guests. So I want to ask you, what is the best advice you've ever received in your career?

Yehonathan Sharvit: 32:26

Yeah, the best advice I received is when I want to explain something to someone always start from a concrete example, always, always, always a concrete example that speaks to the person in front of me. And from this example slowly by slowly. Uh, step up into the abstraction and always make sure and confirm that the person stayed with me and understand not before a, before being aware of this advice, I use to start from theory and abstract stuff and claims, and it never worked for me. And when I started to, to speak concretely with concrete example, It's much easier for me to connect to people and to go where they are instead of bringing them into my realm. I go down into their, uh, their stuff.

Fernando Doglio: 33:24

Interesting. Okay. And it looks like you use that on the book as well. Very, very good advice. Uh, what's the most exciting project you worked on?

Yehonathan Sharvit: 33:34

Yeah, the most exciting project is my first open source project. It's called Klipse and it's a JavaScript plugin that makes it possible to embed interactive code snippets in blog posts. Uh, and it, it works with many different languages, JavaScript for sure. Or closure Ruby, Python,, Java, Lua, scheme, brain fuck, uh, many, many languages. Um, and. When I read a blog post or an article that leverages interactive snippets, it's very fast for me because I can experiment with what the author claims right in my browser and read the code and modify the code and run it again. And I started this project, uh, in 2017, five years ago. And it was very exciting because I used it for my blog. That's how I became a blogger. And lots of people use it from on their blog and lots of fork and pull requests and issues and comments and, and Hacker News and the lots, lots of fun stuff. So that was my entrance into the open source world from the contributors. And by the way, I just, as a disclaimer, I am not a compiler guy. I didn't write any, uh, interpreter in JavaScript. I used open source interpreters available. I just glue them together. That's the only thing I did, right?

Fernando Doglio: 35:11

Yeah, no, absolutely. I mean, that's the smartest way to go about it if you asked me because there is already a lot of work already done, there is no need to reinvent the wheel every time. Um, final question. What is one thing you wish you knew when you started coding.

Yehonathan Sharvit: 35:29

Mm JavaScript. When I started coding in 2001, I started with C and C plus plus, and it was such a nightmare and I had so many headaches. I am not, I am not smart enough to code in C or C++. I cannot do that. I had to fight with the compiler every time, and it was a nightmare. I had 10 years of suffering with a ugly technology and. I was lucky enough to discover JavaScript in, uh, 2009, but I wish I wish I discovered it earlier. Yeah.

Fernando Doglio: 36:05

All right. That's it. Thank you so much. Uh, for being here, please tell our listeners where they can find you, and if you're working on something else, something you want plug it's your, it's your time.

Yehonathan Sharvit: 36:19

So I'm quite active on Twitter. My Twitter handle is @viebel. V I E B E L . I have a blog it's blog.klipse.Tech B L O G dot K L I P S E dot T E C H. If you, if you purchase the book from the Manning website. There is a forum live forum. So you can ask me questions there, or you can ask on Twitter or you can send me an email. It's easy to find my email online. Um, right now I'm taking a break. I've completed the book and it's going to be printed very, very soon. I really enjoy the process of writing a book right now. I don't have any idea for a second book, but, uh, One idea maybe would be to address the, what you mentioned, Fernando, that it's not easy to see the principles and the highlights of the book. So maybe I will write a non story, a version of the book and who knows. I'm waiting for the inspiration that will hopefully come for a new idea.

Fernando Doglio: 37:25

Yeah. Cool. Absolutely. Uh, if it doesn't then just rest because writing a book is not easy. I should know. Uh, so, um, enjoy, enjoy the time the break the, and that is, that is all we have. That is all the time we have. Thank you again so much for coming in for speaking about this to me and the audience. And that's it. See you guys on the next one. And thank you again for being here.