Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#70 - Yehonathan Sharvit
38 Plays4 years ago
The second coming of Yehonathan on defn, who brought us Klipse, in which he talks about what/why/how of data oriented programming and why Clojure is the best language for data oriented programming with a dash of christian theology.
Recommended
Transcript
Celebrating Four Years of DeafN Podcast
00:00:15
Speaker
Welcome to DeafN. It's episode number 70, almost four years by May, I think. Yeah, I think we're now part of the history now.
NFTs, Dogecoin, and Dog Lovers
00:00:26
Speaker
I think, you know, I think if we started a bit earlier, we would have been on that golden record that we sent on Voyager. I mean, we are like that level important to the, you know, humanity these days, our podcast. In case, you know, you don't you didn't realize the people who are listening, you know, you're part of a phenomenon now.
00:00:44
Speaker
It has been going on for four years. Is that in a bullshit? I think what you want to say is that this podcast will be the future NFT. Yeah, exactly. The one and only. Each episode is going to be one NFT. Each episode, yeah. Or maybe just two. Each track. Exactly, each track, yeah. So yeah, prepare to sell your belongings and buy our NFT shit.
00:01:12
Speaker
with your whatever the crypto coin that that fancies you know the dogecoin we only accept dogecoins yeah yeah the doge to the moon anyway um we're doji people we're not cat people you know we're not cat coins yes the cat coins you know sorry they just don't move it for me but
00:01:32
Speaker
Yeah, we got to take a stand, right? I mean, the world is polarized between cats and dogs, and we know dogs are better. There is one thing that we agree on, right? Apart from, you know, you're using inferior editors and all of the crap. Well, we could rethink this, the sub-context of the podcast now. Like, it was a vegetarian, closure of vegetarian podcast, but now it can be a closure of vegetarian, dog-loving podcast.
00:02:00
Speaker
Yeah that is number one number one because you're the vegetarian podcaster about like cats and fuck those guys. Anywho so on that happy note.
Welcoming Yonathan from Israel
00:02:16
Speaker
So I think in the last couple of episodes, we have this trend of bringing back our guests again. So on that, we're not breaking the tradition, at least not in this episode. So we brought back Yonathan all the way from Israel.
Exploring Clips and Data-Oriented Programming
00:02:30
Speaker
And I think last time we spoke a lot about clips and then this expirative programming, all sorts of weird stuff. So please go and look at, or not look at, listen to that episode first, because otherwise you're missing a lot of content already.
00:02:45
Speaker
But now I'd like to welcome you back on the episode and onto the podcast. Hello, another. Hello, Ray. Hello. Yes. Yes. Well, you've been a busy boy, haven't you? You know, you're not just, uh, you aren't just sticking with clips. Yeah. Yeah.
00:03:09
Speaker
Yeah, someone asked me what is the connection between clips and data-oriented programming. And I was, what the fuck? Why should it be a connection? But the question sticks on my mind and suddenly I found the connection. Oh, so they're right then. Probably, you know, when you ask a dumb question, that's the best way to
00:03:38
Speaker
to stick to capture someone's attention. Hey, that's our job, asking them a question. Don't put that responsibility to other people. Someone already did, one question less to ask. Okay, we'll definitely be having lots more of stupid questions as we go along.
00:03:59
Speaker
So first, let's get started. So what have you been up to
Success of Clips in Clojure Websites
00:04:05
Speaker
these days? Because we know Clips is one of the amazing piece of work that you've done that has been now, I think, practically used in most of the website these days if they want to show off any closure stuff. And the second thing that you're talking about is data-oriented programming. So what about it, and what are you working on in closure world these days?
Clojure in Cybersecurity: Yonathan's Experience
00:04:24
Speaker
In closure, I work full time for a closure company in Israel. One of the few closure companies in Israel in the domain of cyber, you know, smart people from Israeli army that takes all the secret from
00:04:44
Speaker
how to attack terrorists and they make a lot of money out of it. So I'm not as smart as those guys, but I'm a decent Closure developer. And for some reason they decided to use Closure.
00:05:00
Speaker
which I was really happy to discover. And so that's what I'm doing most of my day. I'm lucky. You're fighting terrorism with closure. Is that the headline news? Not fighting terrorism, but actually it's more
00:05:23
Speaker
threatening industries and scary them that they could be attacked by terrorists or Our tool to
Psychognito's Cybersecurity Innovations
00:05:37
Speaker
But it's slightly better than, are you fighting terrorism? No, actually. This is actually internal catering application that we are trying to figure out. The company is ordering pizzas from my application. Close enough. Fighting terrorism by providing pizzas.
00:06:01
Speaker
But yeah, cool. But what's trying to use, by the way, is it a top secret or is it something that you can announce publicly on this hugely popular podcast? Yes, I can announce. Dangerously popular. So the company is called Psychognito. And they provide something that they call attack surface management.
00:06:29
Speaker
So the customers are big, big enterprises that have millions of assets online. And they simply don't know what they have. Or even if they know, they don't have any tool to manage all the assets and the security hold that they might have. So that's the attack surface of the company. And Psychognito's kind of
00:06:57
Speaker
detect automatically what are all the assets of a company. And they do it 80% automatically. And that's quite a nice algorithm. Just by having the name of a company, the technology is able to discover the graph from one node to another node to another node and say, and discover all the assets that belong to the company and then find the vulnerabilities.
00:07:28
Speaker
That's the product. Yeah, this is a domain that we haven't heard much of closure in the cybersecurity area. This must be something novel, at least.
00:07:42
Speaker
Well, if you listen to the most recent episode of Cognicast, my friend Mia, who was a great impersonator, not, she mentioned that she's working for a cybersecurity company as well.
00:07:58
Speaker
Oh, that's also closure. Also closure. Yeah. So I think that, but is it, is it really like core cybersecurity thing or is it actually one of those? Proper, proper, like Cisco. Internal, internal task management system. No, no, Cisco, Cisco. Oh yeah. Cisco. I think we know Cisco have been using it for a long time, right? Yeah. It's a, yeah. Anyway, they split, they split the, the, the part that deals properly with the
00:08:26
Speaker
Vulnerability detection is written in Python. And the part that analyzes and pass all the data and makes sense and builds the graph is written in Clojure. So they can afford the slow bits for the vulnerability detection.
00:08:47
Speaker
Exactly. Nice. How big is the team actually? Around 40 developers. Something like that. Oh, wow. Okay. And so back to Vijay's original question, what kind of tech, what kind of tools do you use? Closure tools, what kind of stack you've got there? Or is it just all home-built stuff? No, home-built stuff. And right now we are integrating Mali.
00:09:19
Speaker
We have actually a very nice habit. Once every two weeks, we do a meetup internally.
Internal Meetups and the Adoption of Mali
00:09:29
Speaker
And once it's an internal, it's an employee that gives the lecture and every other two weeks it's someone from the outside. So we brought Christophe Grand, we brought Timothรฉe,
00:09:45
Speaker
And we brought Tommy to talk about Mali. And next week we'll have Babashka. And it's quite interesting. It's really exciting to have people give, you know, stars from the Closure Community gives talk for 30 minutes, half an hour. We had Frederic Przyลski, a French academic. So it's quite
00:10:15
Speaker
I like it. Nice. Yeah, very good. And that's what triggered the integration of the adoption of Mali after he gave his talk and explained what's the benefits of Mali and why it's better than spec, etc. We decided to adopt it. It's the new way of promoting open source.
00:10:39
Speaker
Yeah, I think that I used to work in India in one of the big names, one of the
00:10:47
Speaker
Yeah, Oracle and these big companies. And we used to have that as well, like weekly, not weekly, but the monthly special guest coming in. I know Google does that a lot as well. Sometimes completely non-technical people like physicists or somebody just to inspire people, which is pretty cool. I mean, when you're at that scale, it's much easier to get those people.
00:11:10
Speaker
But if you had a startup with two guys or two girls sitting somewhere, then asking Neil deGrasse Tyson to come up and then give a lecture about Pluto. That's going to be like an unreachable target. But this is super cool, by the way. But 40 developers mostly working in Clojure, or is it a division between Python and Clojure? I would say 80% Clojure and 20% Python.
Clojure Development in Israel
00:11:37
Speaker
Wow. So is it like the biggest closure company in the name? In Israel, there is one big company called apps flyer. I know if you heard that. Yeah. Yeah. Yeah. I know. I know. Yes. So there are I think 300 closure developers or something like that. Wow. Wow. Okay. Yeah. Yep. I remember because I think they, uh, we, we had a couple of speakers from apps flyer for Dutch closure day. Yeah.
00:12:01
Speaker
So those are ad companies, right? Those are mobile ads and something like that. Analytics, yeah. Yes, exactly. So in your company, now you've went from 1 to 2 to 5 to 10 to 20 to 30, your developers, and it seems like you're operating around a particular product.
00:12:29
Speaker
Agile, do you find closure maintains itself or what are you doing to maintain closure as kind of agility in the face of scale? Have you had to make some big decisions or some design choices that help you? First of all, it's a data pipeline. The core of the product is a data pipeline, so it's split in
00:12:58
Speaker
multiple services. So each piece of software is not too big. Right. That's good. It's already a good decision then. Yes. And the struggle is when we need kind of an understanding of the schema either for, you know, when the developers starts coding and of course there is no documentation, no, nothing because good code doesn't need to be documented.
00:13:27
Speaker
No, absolutely. Sure. And then you don't know what you have in hand. You have an IP, probably it's a map, but what are the fields in the map? You need to put a break point or something and open up the repo and discover example by example and guess what is the model.
00:13:50
Speaker
And sometimes it's painful, I would say. The dynamism and the flexibility of closure, sometimes it's painful. And especially when it's nested, when you have a full hierarchy, you have a map and a nested field and another nested field and then you don't remember at what level of the nesting you are. And you make stupid mistake and you forget to put something in a vector and it doesn't work and you don't understand why.
00:14:21
Speaker
So I hope that Mali would be helpful. One, for documenting, and two, even for catching locally when we develop. Structural coverages, yeah. Yes, when you just forget a field or pass the bad field or bad type or whatever. But you didn't use any specs for this one? No, no, no. We don't use specs. You haven't looked into these things. OK. No. And what's interesting is that there is
00:14:51
Speaker
Uh, and I don't, I'm not sure that money is going to solve that, but there is for psychognito, there is one big data model that is shared across the dozens of services. You know, an IP is the same, whether it's, uh, by this producer, by this worker, by the app, by this or that an IP will always have the same field and the same semantics. And we are looking for ways to put the schema somewhere.
00:15:21
Speaker
But not inside the app. We don't want to have the schema as code. We want to have the schema in a file that somehow is going to be shared between all the services or maybe a la carte. Maybe we have a file for IP, a file for domain, a file for IP ranges, and somehow aggregate. So it's an interesting challenge.
00:15:45
Speaker
federation of schema. So you're thinking something like a schema registry. I mean, usually in the big data world or in Kafka, for example, you try to have a schema registry where you register all the schemas and then each application is pulling some specific parts. But they have that in Mali actually. They have different types of schema registers that you can
00:16:08
Speaker
You can register things and have different kind of models around what those registries look like. So that means you can run it as a service separately, or is it part of the same application? Well, you can always run anything as a service, can't you? It's just data, so you can store it somewhere.
00:16:30
Speaker
And then you can pull on, it's up to you how to run it. You know, there is an in-memory registry that you just, you know, like, I expect you just def into, you know, but, um, but yeah, you can definitely run a service with it as well. But then we need to be careful because Mali allows you to put predicates as code. And, and I'm not sure it's, you know, if for our use case, it's going to be a good practice.
00:16:56
Speaker
because we want the schema to be static. But that's true of spec, isn't it? Yeah, for spec even more. But maybe something like JSON schema or in the spirit of JSON schema is maybe more appropriate. I don't know. Interesting. We are experiment. And I think something that interesting although
00:17:21
Speaker
Python is a small part of our tech stack, but we always think generically. So the code, even when the code is written in Closure, when services communicate, they don't communicate with Eden. We prefer to communicate with Jason to be more friendly from non-Closure code. And you know, from... And it gives you choices. Yeah, it gives you implementation choices, I guess, as well then.
00:17:51
Speaker
Yes, and for tooling also, Eden is great, but you don't have tools for passing Eden or observing Eden in the browser or exploring.
00:18:04
Speaker
What about, and we were talking about this before, but the graph sort of concept, because everyone is like, well, there was a lot of buzz a few years ago around GraphQL from Facebook, and then there's different libraries popping up from the closure world, from NewBank and from Walmart.
00:18:32
Speaker
Is that something also you looked at? You've looked at this graph type? Yeah, we have integrated the graph QL, the Walmart documentation. And I don't know if I like it or not, because the graph QL is very, very rigid. For example, if you have
00:19:02
Speaker
You cannot say I have a map and I don't know what are the fields. Even in, somewhere, even if you know, I don't know, 90% of the fields, but somewhere you have, for example, not a DNS record, but a record with, forgot the name, not a DNS, register with, you know, arbitrary fields. And that's life. There are in the, I forgot the name, where you register a domain, you have to...
00:19:31
Speaker
You have like a map of data and you don't know prior what are the fields. And GraphQL does not allow you to express that, to say I have just a JSON. So you do, either you say, okay, I have a string and the client will pass it as JSON, or I have a list of tuples where, but it's not really a map and it's been in the US.
00:20:00
Speaker
Yeah, yeah. But GraphQL is... It's very rigid. It's very, very rigid. Because it requires schema, right? I mean, you need to define the schema upfront to put the stuff in GraphQL and then query it back. And also you are not allowed in the, let's say, in the JavaScript where you build the query, if you build from the front end or close your script, there is no real way to manipulate the query as data.
00:20:26
Speaker
You have either the string, the GraphQL syntax, which is amazing and it's not JSON, it's something very human-readable. Yeah, somewhere in the middle. But you cannot manipulate it programmatically. It's the same thing as SQL. You can pass it to an abstract syntax tree and then you cannot manipulate. And if you just want to say, okay, I have two queries and I want to compose into one, you cannot do that. You have to do it statically.
00:20:50
Speaker
and have a file and a query and have a Webpack process that compiles the file and create a JavaScript object. The final one is the RDF, which I guess is like the atomic crooks, the whole data log type thing. Maybe that's what we should be getting excited about.
00:21:20
Speaker
Maybe. Yeah. I mean, you know, I'm not joking about that because to, because to me, I mean, you know, Molly is a bit like that. Um, you know, and I think having like, uh, we'll come onto the book that you've written, but you know, having like loose, loosely defined entities, no entity attribute, uh, value type things seems like a perfect model because it's super flexible. You know, did you, do you, do you guys know, um,
00:21:51
Speaker
Oh, this guy from Brazil that created an awesome library called... His name is Wonker Lucio. And the library is... Oh yeah, Bottom. Yeah, Bottom. I think it's a...
00:22:08
Speaker
I think it's much, much better than GraphQL. And it's in the spirit of RDF. And it shows me the other day, all kinds of amazing stuff that you can, the query discovers the topology of the graph on its own. It's really amazing. And it's possible just because it's stored as, you know, data, very simple data.
00:22:33
Speaker
Okay, let me let me transition to the book with a question for us. Not a dummy question. The question is going to be, do you guys think or do we think that namespace keywords is inherently related to data oriented programming?
00:23:00
Speaker
Yeah, I think so. Oh, that was too fancy. Okay. No, I don't think so. No, no, no, no. That's a terrible idea. It's good you've got the video there, you know. Exactly. You can see Jonathan going, no, no, no, you idiots. Don't fool yourself. Yeah, you've got to warn us for these trick questions, Jonathan.
00:23:26
Speaker
You know, this is bad treatment of the podcast host here. Cut him off. Stop him.
00:23:36
Speaker
But what is the relationship then with the name spaced keywords and the data programming or data oriented programming? Maybe it's better to say, what do you mean by data oriented programming? That's a better place to start at. Let's get some background. I mean, we've been bullshitting for like 20 minutes now. So let's start talking about the real stuff and we'll circle back to all this other shit. So you're writing a book, Jonathan.
00:24:05
Speaker
Yeah, I'm writing a book called Data in the Programming. And it has nothing to do with it. I've had a look at the early access, and I can say it's very, very good. So I think congratulations on the work you've done so far. And I'm pretty sure you'll have it completed soon. That's a very interesting concept by Manning, the fact that they released the book before it's totally written.
00:24:31
Speaker
It's very agile and I wouldn't expect from a publisher, a book company to be so agile and innovative. And already I got feedback from the readers and I've changed the remaining parts of the book. I've decided to include new chapters and to put away other chapters and I get feedback for about mistakes or
00:24:56
Speaker
things that are not clear. So it's very, very valuable for me as an author. And for the people that will buy the book at the end, it will be a better, higher quality than the one that the quality of the book. Like we do, you know, in SAS, we deploy an MVP and then we improve or pivot. And it's interesting to apply these ideas to
00:25:25
Speaker
So it's a book that is not about closure. Actually, I started three years ago to write a book about closure, and it got into the same stage of MIB, but it was a total failure. So the publisher told me, we are not going to follow the project, but we like you. So if you have another idea, we are open to hear, but not closure.
00:25:51
Speaker
Yeah. And that's the idea I came up with data-oriented programming. And right now the book in terms of sales does really well beyond expectation, beyond my expectation. And so on one hand, it's not closer. It's not targeted at people who want to learn closer, but it's nothing but closer. It's all, it's full of closure.
00:26:20
Speaker
So it's close your spirit. So you tricked them. Yeah. I feel like Jesus, you know, he was a Jewish and he discovered that it was too complicated to convince everybody to become Jewish. So he took the best part of the Judaism and sell it as a Christian. Made data in the programming. So Christianism is JavaScript in this case.
00:27:01
Speaker
I don't think that we are going to be able to bring- Let's hope you're not going to get crucified by the clergy. I hope so. Yeah, I hope so. I hope so. And I'm not sure. I'm not sure. Well, from the stuff I read in the book, I think everybody will be very pleased that you're representing, even if it's not the- No, but actually it's not the Jewish that crucified Jesuits, it's the Roman.
00:27:10
Speaker
Maybe. Jesus script. Jesus script.
00:27:31
Speaker
The Romans. Yeah. Yeah. Yeah. So you mean all the C++ people will get you. If you're very precise about it, the Jews could have stopped it, but didn't. You know, I think the Romans kind of like Pontius Pilate did offer to have him not, you know, to be dealt with
Yonathan's Book on Data-Oriented Programming
00:27:50
Speaker
by the Jewish. But let's not get into that because it's going to be a very bad story. I can really imagine Java Fox crucifying me.
00:28:00
Speaker
and pretending dynamic for dynamic programming is a good idea. And I could see Richie, he not saving me and letting me be right. So perfect. Yeah. Okay. Now that analogy is out of the way that we can talk about data and programming now. Okay. So, so really, uh, for, for me at least another, if it's the same for you, I feel that
00:28:29
Speaker
I am smarter in closure that I used to be in Java or C++. I've been able to write code that I was never able to write. You know, the readers that they ask when they want to interview. I was really bad at it. Really, really bad. I could not solve any of them. And in closure, my fingers solve them. I don't have to think.
00:28:57
Speaker
And I've asked myself, what is it enclosure that makes it so different than other programming languages? For sure, the fact that it's functional. But there are many functional languages. For sure, the fact that it's a list and we have the repel. Yes, great. But there are many languages with the repel. And after turning around and around and around,
00:29:25
Speaker
discovered with the help of the Closure community that what makes Closure stand out away from any other programming language is the fact that it's data-oriented. And I make a real work of research trying to formulate very precisely what is the meaning of being data-oriented programming, or what are the principles
00:29:52
Speaker
the concrete principles of data oriented programming. And you know, if you listen to Rich Hickey's talk, you probably feel illuminated and wow, it's amazing. But it's very, it's at a very, very high level. It's very abstract. It's, it's, it's not tangible and it's very hard to, I know if you try it, but if you try to take Rich Hickey's idea
00:30:17
Speaker
and share them with someone that is not convinced, it will be very hard because you are probably not as talented as Rich. And it will be hard to convey the ideas. Yeah, I mean, we can dispute that. I mean, as you know, our stupidity is beyond imagination. So we will tell you that, yes, we are smart enough, Rich. OK. The ideas are when you listen to them, you say, oh, OK, yes. But when you try to explain, you miss something.
00:30:46
Speaker
And I wanted to be very, very, very concrete and done to earth. What does it mean, data-oriented programming, and why it is beneficial? And I came up with three principles, three simple principles. And you're probably... The three commandments of the Lord Jesus. The Trinity.
00:31:13
Speaker
It started becoming a theology. Yeah, it's going to be a theology podcast. Yeah. Nice. Yeah. If you look at my birth date, you will be very, very surprised. Do you have a guess? Is it the sixth of the sixth 1966? No, no, better, better, better. Okay. Oh, wow. Okay.
00:31:34
Speaker
It's a Christmas. Jesus birthday. Yeah. It's a birthday of Jesus. It's the 31st. Okay. 25. Mine was better though. 6th of June 1966. Oh, you are 6th of June? You was born on 6th of June? No, no, no, no. It's just 6th, 6th, 6th, 6th. Mark of the beach. So the holy trinity is what we have, the father, the son, the
00:32:02
Speaker
I don't know. The Holy Ghost. The Holy Spirit. Number one is that we want to separate code from data. We don't want to be object oriented. We don't want to have data hidden or encapsulated in objects, but that's an easy one. Number two, we want data to be immutable. We don't want any side effects or non purity.
00:32:32
Speaker
And that's okay. And number three is that we want before you go on, number one, sorry, go on. Are we going to discuss each of these three? Yeah. Okay. That's cool. What's number three? What's number three is that we want to represent data as data with generic data structures. That's it. Before we, before we, uh, we drilled a, uh, we deep dive into each of them.
00:33:02
Speaker
just to make things tangible for the folks that listen to us. So number one, separate code from data. It is the, the, the discussion between object oriented languages and let's say non object oriented languages. Number two, no side effects. It's functional programming. We don't want side effects. Yeah. And until now,
00:33:29
Speaker
You can be in OCaml or in Haskell or any language like that. But number three that represent data as data is quite specific to Clojure and to JavaScript. But JavaScript doesn't have the number two, that data is immutable.
Functional Programming Meets Data Structures
00:33:47
Speaker
So you could say that data-oriented programming is like functional programming plus generic data structure.
00:33:56
Speaker
Or you could say it's like JavaScript plus immutable data. Or you could say it's closure. OK, so data. That's the background. JavaScript has objects, though. Yeah, but you could do, let's say you do JavaScript without object, without classes. Yeah.
00:34:19
Speaker
And it's quite idiomatic. You could also do Python without classes and Ruby without classes. I think in JavaScript, nobody will shoot you if you don't use classes. In Python, it's dangerous not to use classes.
00:34:40
Speaker
Well, let's go back to number one, then. Go back to number one. So number one is like no debt or encapsulation, essentially. Yeah. Which, like you say, is the fundamental cleft between the two. Let's say it's the schism in religious terms, you know, between the two churches. Yeah, exactly. But I'm kind of interested in that because, you know, I mean, I get it. I'm sold. But
00:35:08
Speaker
These people that like their types, they like this encapsulation. What's your argument against it? Apart from, we all know it. Since you're going to be very concrete, what is your bullet in the head? Let's go bullet in the head. It's better. First of all, let's identify the enemy. The enemy of principle number one is not types.
00:35:38
Speaker
is object oriented. And the magic card that I have. It's getters and setters, basically. No, it's more than. It's mutation through some object method, essentially. Yes. Adding behaviors to the data. And I spent the whole chapter of the book
00:36:07
Speaker
attacking, or not attacking, acknowledging, let's say, the inherent complexity or the tendency to complexity when you build a system with objects. And I do, I did the exercise. So in the book, I take an example of building a library management system. And I implemented it, at least at the level of the design, as if I were
00:36:32
Speaker
a Java developer. So I really had to feel the pain. It was very, very hard. And the number one argument is complexity. And I cannot draw in the podcast. I mean, I can't draw, but nobody would be able to see my drawing. But imagine a class diagram.
00:37:00
Speaker
a classic class diagram. So you have class and the class has relationship with other classes. And you have many kind of relationships. You have inheritance, you have composition, you have association, you have usage. Let's say that the four basic ones. And very, very quickly, your class diagram becomes complex.
00:37:28
Speaker
Okay. Now imagine you take the exact same diagram, exact same diagram, exact same design, and you do something very, very simple. You take every class and you split it into methods and data. So methods, all the methods will be static and they will receive data as an argument.
00:37:52
Speaker
And just by doing this split, instead of one complex graph, one complex diagram, you have two simple disjoint diagrams. And when you see it in your eyes,
00:38:09
Speaker
you feel immediately that the resulting system is simpler. It's less entangled, less relationships. You can understand each subgraph in isolation. You can think about the relationship between data on their own. You can model your data before you think about what are you going to do with the data and what are the functions. Or you can start with the function and then design the data appropriately, divided from query.
00:38:40
Speaker
So that I think the number one argument and it's very visual. What about people who would argue then that, you know, um, I want to have a safe way to change the data and object orientation gives me a safe way to change data. What do you mean the safe way to change data? Well, I've got an object, it's got a method on it called, you know, uh, I know change the clock or something.
00:39:06
Speaker
You know, and I can do that in my object and you don't need to worry about it. I'll just make it happen. So I don't need. And also the good thing about that is it's atomic according to that object. Whereas if I have the data outside, then anyone can fuck with it. Yes.
00:39:28
Speaker
I'm trying to play devil's advocate here. I know, I know. And you are very bad at it, but let's pretend that you are... Let's pretend that you really mean what you asked. So number two is easier for me to tackle. And the answer is because we are going to make sure the data is immutable,
00:39:57
Speaker
We don't have to worry about what's happening if someone is going to change my data because nobody is going to change your data. Because the data is immutable. So the principles are not independent. If you do a separate code from data, but you allow mutations, then you shoot on your foot. So it won't be safe.
00:40:19
Speaker
The number one. I think the thing that object oriented people get very confused by the fact that you have immutable data, but I want to change data. Yeah. Okay, so I can go also into something a bit philosophical in a moment. But before that, let me rephrase your question and I don't have a good answer. I would just acknowledge the trade off. When you have an object,
00:40:49
Speaker
in your hand, you know what are all the methods that can touch the object. It's the method of the class. And I don't mean just for refactoring purposes. I mean, let's put aside
00:41:05
Speaker
the refactoring safety or the easiness of doing refactoring. It's a different topic. It doesn't have to do with complexity. When I talk about complexity, I talk about the inherent complexity of a system that run, not the easiness to change the system. That's a different one. And we can also, we could talk about it, but it's, uh, so let's put that aside.
00:41:29
Speaker
But there is an issue or there is a limitation when you separate code from data, when data is decoupled from code, when you have a piece of data, when you want to figure out what are all the functions that know how to deal with this data is difficult.
00:41:50
Speaker
It's difficult. And I think that with tools like Condo or CLJ Condo or stuff like that, there are ways to say, OK, I have a map with those fields. What are the functions that can receive this kind of map? But it's just the beginning. It will never be as straightforward as asking the question in object-oriented world.
00:42:15
Speaker
And also, maybe the question is wrong. No, maybe that's a wrong question. If I can play a non-devil's advocate for a second, I would say that question is, you know, if we go back in the history, you know, we'd say we'd rather have like a thousand functions over data than a thousand data structures.
00:42:35
Speaker
So you know i mean we can talk about those but i think the generic the generic argument about complexity vs simplicity is that you might want to tie down a particular transformational function on this particular data but why. Why do you want to do that you know what i have an open system i can i can i can play not okay. I have a customer in my hand i have data that represent the customer.
00:43:05
Speaker
And I want to know what are all the, and let's say I want to upgrade the customer to VIP. Where do I look for this method? Where is it? Or I want to retrieve the password of the customer or the purchase history of the customer. Where would I find it?
00:43:23
Speaker
It's difficult, but I think that it has to do with easiness. I mean, for someone that knows the project, it will be easier than for someone that doesn't know the project. It's not inherent. It's not more complex or less complex. It's easier. And I think that the way we approach data in data-oriented programming is
00:43:53
Speaker
almost like the way we approach data that is in a database. I mean, when you have a table in a database, you don't know what are all the pieces of code that retrieve data from this table. It's a question with no answer. No, you don't want to know. You don't want to know. And you don't want to know, you don't want to allow yourself to rename a column in a table.
00:44:15
Speaker
and say, okay, please bring me a tool that when I rename a column of the table, all the code is going to be updated and it will work automatically without breaking all customer nodes. Hey, but if you use a Hibernate, you know, if you use an ORM tool,
00:44:37
Speaker
Yeah, but like you say, then you're kind of limited to the code rather than all the kind of reporting tools and all the other bits and pieces. So you haven't got an open system anymore. That's the advantage of the data orientation. Yes, and it's open and it has limitations. It's less easy. I would say it requires a given given
00:44:57
Speaker
Given this trade-off, would you say that data-oriented programming fits some domains better than the other domains? Yes, yes, yes. And the domain that it fits for is what we call information systems.
00:45:15
Speaker
It's not good for game. If you want to build a game, you don't know a game is data-oriented programming. If you want to write a compiler, you don't write a compiler with data-oriented programming. When you know your domain and when you know exactly what fields are going to be in your data and it's not dynamic and the system is closed, the data of the system lives in the system and ends in the system, then it doesn't make sense to have data-oriented programming. But when you fetch data from somewhere,
00:45:45
Speaker
And you need to pass the data to another one in many different formats. And you need to be, then the ability to be open and to manipulate data and to pass data forward, even when you want to set only two fields and to pass all the other fields without understanding, without having to care about what are the other field is really important. And that's what we do every application.
00:46:16
Speaker
I mean, one could argue that a compiler is somewhat of a text-oriented, data-oriented system. Once you get to an AST, it's data. Yeah, but it doesn't accept random shit, right? I mean, a compiler is very strict on what it is accepting. Yeah. You have children and, I don't know, first argument, second argument, and that's it.
00:46:44
Speaker
Yeah, yeah, because you're following you're following a very rigid schema, right? When you pass it already.
00:46:49
Speaker
You're also for a specific language. Yeah, but I mean, yeah. Okay. But I mean, I think a lot of, uh, a lot of languages like closure, which is a, which are dynamic are not so obvious. Yeah. And they're still, but I mean, closure closure has a compiler. That's because it only needs like what seven forms. That's it. And then you can, you can build the whole shit from that one. But if you see all other languages, they are there, they have a very specific, um, definition of the language and you can't deviate from it.
00:47:17
Speaker
I can't suddenly just change in Python, there is def, then I'm going to just change it to, I don't know, fad. That's not how it is going to work because it has very specific lexical elements that it is looking for. So I think in that sense, compiler is a closed domain. Well, but I mean, it doesn't have to be an open domain to be data oriented, does it?
00:47:36
Speaker
I'm using your movies in your definition it does your husband but i don't have to but it's more beneficial when the data leaves originally outside of your application. I think that's that's that's the best if you can give. Before does the data leave somewhere before you write the program or not if the answer is yes it is in the database then it makes sense to represent data as close.
00:48:06
Speaker
as it lives in the database and not as close as you want in your program for easiness reasons or for convenience reasons. And that's the tension. That's the tension. Do you start from your needs or do you start from the reality?
Immutability Trends in Java and C#
00:48:23
Speaker
And in that algorithm, we say we start from the reality. My needs are real though. Yeah, your needs are real.
00:48:32
Speaker
Sorry. And by the way, it's really interesting to see that even languages like Java and C sharp, they promote records, records in Java 14. There is something called a record, which is a class with only members, no code.
00:48:55
Speaker
And it's immutable. And it's automatically serializable. And you get a hash code. The value object. The value object, exactly. The value object.
00:49:12
Speaker
So I think that even Java folks- I remember going to a talk by someone. I think we're going to a talk by, I don't know if it was one of the Java compiler guys, but he was saying that, yeah, value object. If it's a value, it's not an object. If it's an object, it's not just values. No, these two things do not exist. Yeah, just value object.
00:49:37
Speaker
But, you know, of course it does exist because, you know, like, like you say, in the end, like if you're doing a lot of water, you know, a lot carrying of water between, between one system and another system, it makes no sense to carry all these functions along, along with it.
00:49:52
Speaker
So I think people, you're right. I mean, people have intuitively kind of gone for that kind of stripping away of objects through just to data. And I think a lot of languages have maps and stuff like this, which allow for a weak typing. Almost all languages here have that. Yes. And here I have a surprise for you guys.
00:50:22
Speaker
How familiar are you with the implementation of immutable data structure in Clojure? And the trick that makes it efficient? In Clojure or in Java?
00:50:37
Speaker
In Java, obviously. Just ask me anything. Ask me anything. We want to talk about the depth of those trees, get into it. Which line number in the code?
00:50:55
Speaker
So I read probably the only available blog post on it with this drawing and the structural sharing and the HA MT and I was never able to understand deeply.
00:51:12
Speaker
And I was really excited, but when I wanted to explain to a colleague, I made a joke of myself because I started to explain and blah, blah, blah, blah, and I couldn't find my work. So don't try at home. It's very dangerous. But what you can try is to implement a similar algorithm that works on any hash maps. And that's what Lodash does.
00:51:41
Speaker
So Lodash, the most popular JavaScript library has a FP flavor. There will be something called Lodash FP. Yeah. It's immutable. Yes, exactly. It's immutable. It's immutable. And it's amazing. You pass through your regular JavaScript native hash maps. And when you call set or even set in,
00:52:06
Speaker
You could say set at pass A dot B dot C dot D, and then it will create a new version of the app with the change. And it does it with structural sharing. So it's efficient.
00:52:20
Speaker
It doesn't do a deep clone like I would do. And what excites me is that I was able to implement this algorithm, and it's seven lines of JavaScript in any language. It's not difficult. The trick is called pass copying. You copy the pass to do structural sharing.
00:52:46
Speaker
And I was so excited then that I asked myself, so why do we need efficient data structure? If the algorithm works fine with native data structures, why do we need special data structures to benefit from efficient immutability? And there are two answers. Answer number one is that to enforce immutability, to make sure that the data is not changed.
00:53:16
Speaker
But you can enforce that in JavaScript or in Java. So that's a weak answer. And the second answer, which I don't know if it's a good one or a bad one, is that this algorithm breaks when you have too many nodes at the same level. So if you have a map with 1,000 fields,
00:53:36
Speaker
Each time you make a change, you have to do a shallow copy of a thousand fields. And if it's a vector with a thousand fields, the same. Whereas in Closure, the implementation breaks somehow the maps and the nodes so that you copy only parts of the map. You don't copy everything. But I think that in a regular application, you don't have a map with a thousand fields, right?
00:54:06
Speaker
If it's a record, you don't have more than 10 fields at one level. So that might be a very good transition pass.
00:54:26
Speaker
It's a good way to think about it for the languages or for other environments which need immutability, but if you can do it in 10, 20 lines, five lines, whatever, of some language, that's much better than spending six months in a hammock. And reading papers on it. And in OCaml, for example, they have semantics for that.
00:54:54
Speaker
So when you have a record in OCaml with specific fields, like a data class, and let's say a graph of data classes, you could say, I want to do a change in the nested field in my data class, and it will do the structural sharing on its own.
00:55:15
Speaker
OK, so it's built into the runtime already. The compiler, I would say. And they have semantics for that. You could say, I want my user with a change. And the change will be in the product and the price of the product of the user. Yeah.
00:55:37
Speaker
But I don't think there is a big argument against immutability, right? Your second principle. I mean, I don't think there is, I think most of the programming communities now more or less realize that, yes, immutability, at least by default, should be the way we program and you should reach out to immutability for performance reasons or whatever. I think only that is the time when you want to move. Yeah.
00:56:02
Speaker
The only thing I would say about immutability is that it's a terrible, terrible name. Because I think immutability is, you know, it's difficult to understand it. And also because
00:56:19
Speaker
you know you do want to have like change you just mentioned it i want to change something i want to get a new structurally shared copy of it the way i think about it the way i would rather people talk about it is like automatically version managed data efficiently version managed data.
00:56:38
Speaker
Because I know that strictly, academically, it's not correct. Fuck that, because people can't understand, don't know what immutability is. It's overloaded. It means too many different things. But if I say to you, if you could automatically get a version of every single data,
00:56:56
Speaker
every single bit of data you had like gates, you know, you could have get for your data. Wouldn't that be awesome? Oh, it'd be very expensive. Ah, no, we've got tricks, you know, we can make it super cheap. So the diffs are very, very cheap. By the way, it does exactly this trick. It copies every file, every blob, or every pointer to a file in every folder that you change in a commit.
00:57:23
Speaker
And it breaks. If you have a folder with a thousand files, which you don't have, but if you have, you will break it. It will not be efficient.
00:57:34
Speaker
It gets slow. But I think already adding immutability is like Git is already giving significant amount of trouble for people to understand shit because Git is already a complicated system. I think we can just stick with version data. I think that's enough for people to figure out what is happening. I think when we say immutable, if you are not
00:57:57
Speaker
Maybe for us, we have this, I don't know, we are used to it so much that we don't even think about that word anymore because it has a specific meaning to people who are using Clojure or Haskell or something. But the people who are not using it, I mean, if you say mutable, then you're like, oh, that's fucked up, no? That doesn't make any sense. Although it's quite well admitted that mutability is good,
00:58:25
Speaker
In the book, I had to bring an argument and I didn't want just to quote, you know, uh, referential transparency, hidden side effects and blah, blah, blah. So I, I, I had to think in the context of the library management system, what would be the benefit of immutability? And there are two benefits. One that you could restore the system to its previous state, like undo a mutation.
00:58:55
Speaker
very, very easily MTP. And number two, which is very, I found it very interesting, is that you have a way to manage concurrency very cheaply because you can run all the mutations in parallel. And just before you submit the mutation, you check if there are a conflict with a mutation that has finished before you were able to finish. And you do a diff.
00:59:25
Speaker
like in React, you do a div between the two mutations that run in parallel, and sometimes you are able to... The virtual library and the real library. Yes, the virtual DOM. And I think that's an interesting way, because then computing the div is cheap. If you change only
00:59:54
Speaker
the versions through structural sharing, most of the nodes will be the same and you can compare them by reference. You don't need to check the value of the leaves. So the diff algorithm is very, very efficient and it allows highly scalable concurrency management with no explicit versioning. You don't have to say I am version 10, I am version 11. It's only based on the content.
01:00:23
Speaker
Yeah. Lock-free concurrency. Lock-free concurrency. Yes. And that's what, in a sense, that was swap does enclosure. The swap on the atom. So lock-free concurrency means you get free locks, right? Locks are free. Locks are free. Yeah. You can go to jail very easily. But the most challenging one, I think, is the principle number three.
01:00:53
Speaker
the representation of data as data with no types. That's the one where they are the highest number of enemies. Resistance. Resistance. It's either resistance or triviality. Let's call them Philistines for the purposes of this podcast. Philistines.
01:01:20
Speaker
Because we have a flavor of this podcast now. Imagine the discussion with a JavaScript guy. You say, okay, it's trivial. What do you want from me? Of course, I represent that as data. So it's not an interesting discussion. But when you discuss with a guy that comes from a statically typed language, either functional or not functional, he would say, no, I cannot live without a type safety.
01:01:50
Speaker
And why would I want to get rid of type safety? And here, I'm not sure I have good answers for that. First
Type Safety in Data-Oriented Programming
01:02:08
Speaker
of all, it lays on lots of emotions and the conviction and past and et cetera. What I find more interesting is first of all to acknowledge that even in closure,
01:02:21
Speaker
We are not happy to have no type at all, no schema, nothing. It's fine when you write a small script, but when you, when you build a production system, it becomes a mess very, very quickly. So instead of saying a schema or not schema, I would say a couple schema or not couple schema. Should the schema be part of the data or should it be
01:02:51
Speaker
decoupled from the data and available. And in some places I could say, okay, here it makes sense to validate that the data is valid according to a schema. And in some places I don't care when I have a merge function, let's say, between two hash maps, I don't want to say that the merge function works only with the hash maps that has this or that field.
01:03:19
Speaker
I mean, there are functions that are inherently generic. So there is no sense, there is no point on typing those functions. But when we are at the application level, let's say I think at the domain level, it makes sense. At the domain level, it makes sense. If I have an entity that represent the user, I want to make sure that the ID is there and that the, I don't know, the email is there. The username is there. Yeah, exactly. Yeah.
01:03:49
Speaker
I think that that is the main argument for, if I'm talking to a Scala programmer, if I'm talking to a Rust programmer, or even Haskell programmer, I think that is the main argument. Because most of the times, the systems that you are designing, they are not generic systems.
01:04:08
Speaker
Most of the times that the systems that you're designing are systems that have very specific domain and people are used to this DDD concepts like the domain-driven design concepts where you define the nouns and then define the bounded context and within this context, what is the terminology that you're going to use and they mean something.
01:04:29
Speaker
Writing a closure core function is completely different than writing a function that is dealing with, in your case, like DNS system or an IP. Where it makes sense to have that there is a piece of data that I can recognize as an IP,
01:04:46
Speaker
And the operations that I'm performing between two IPs are more specific than the operation that I'm performing on core data structures. So that's the friction, I think, with the static and dynamic languages. Yes. And I think that the language that does it the best right now in 2021 is not closure. I think it's TypeScript. I don't know if you guys tried TypeScript.
01:05:14
Speaker
But I gave it to try because one of the readers challenged me and say, every argument that you make in the book, in TypeScript, I can implement it in a nicer way. And TypeScript gives you types a la carte. So you could write JavaScript, and it's a valid TypeScript. And here and there, you could say, OK, here I want to say I have a map, not an any object. I have a map with those fields. And the semantics of the types is very, very elaborated.
01:05:44
Speaker
And it's dynamic and you could, I don't know all the details, but I run through the tutorial and I was really amazed by the flexibility that it gives you as a developer. So that is the 30% that we are missing in the wrap up. Use TypeScript. Yeah, probably.
01:06:07
Speaker
But I often thought that, you know, I was saying this to David Nolan, actually, was that we should, wouldn't it be a bit nicer in some ways to target TypeScript rather than JavaScript, you know, for like, but, you know, that ship has sailed, I think. But, you know, someone else can write a program that targets TypeScript.
01:06:29
Speaker
as a sort of compile language because then you would actually get all the type safety at runtime if you wanted it. If you had a spec or if you wanted something like that, you could do all that kind of stuff in TypeScript. But you need to bring some of the semantics into Closure, right? But in the end, it's JavaScript because TypeScript is still JavaScript. It's not TypeScript. It's just like ClosureScript. It's just a compiler. I think even it's simpler. I think that when you compile TypeScript,
01:06:58
Speaker
You get a JavaScript with no types at all. It's just... Yeah, that's what I mean. We just either break or say, okay, it's just a step in the middle. So I think it makes any... I did something funny. Two weeks ago, I published something like six challenges.
01:07:25
Speaker
six small exercise that enclosure or in data deployment is very natural to implement and I challenge the community, okay, how would you write it in another language? And I got people that submitted solutions in TypeScript, in Ruby, in Elm, in Elixir, in Go, even in someone submitted in Go. And in TypeScript, it feels very, very natural because you can play with
01:07:55
Speaker
really it's like obviously cutting the ice and eating it or cutting the chocolate and and having it having the cake and eat it yeah yeah you have the cake and you eat it and and i think that's already overloaded right having the cake would also already mean i'm eating the cake yeah but yeah i think as i said maybe
01:08:20
Speaker
Well, I mean, there are other niceties that you're getting. Well, you can do data-oriented programming in TypeScript, but you cannot do all the stuff that you do with Clojure in other languages. So that's probably, you know, still like a USB of Clojure.
01:08:38
Speaker
You still have the lispiness of it. All the advantages that you get because it is a lisp, you don't have that in JavaScript or TypeScript. You can't do the same level of metaprogramming, for example. Those things are
01:08:55
Speaker
Also, the language is easier to learn because there are not many complex shit that you need to learn to be productive. That is still a pro-closure argument. I think we're on a very thin ledge though. Metaprogramming is all we've got. I'm sorry.
01:09:18
Speaker
You can write code that writes code. What do you mean? Yeah, that's amazing. Isn't that? Yes, shut up. Use closure.
01:09:29
Speaker
But I think in the tips of the data-oriented programming, I get the concept now that all these pieces are basically leading ideas behind Clojure, right? So you would say that, right? This is how you build larger Clojure programs with still some pain points, which is, as we discussed, introducing the types, introducing a bit more confidence into the system, I would say, at some level, when you're programming at a certain level.
01:09:56
Speaker
Super cool. So how far is your book now? So can people go and buy it right now? People can buy it right now and the price is lower. I think it's $27 for the digital copy. And every time a chapter is released, every month or something like that, they get an email with the new content. And they can collaborate and ask questions
01:10:27
Speaker
Yeah. Does it have its own website or is it something that people just go to manning.com and then search for data-oriented programming? You write data-oriented programming. And it's, you know, maybe we can end up with something that is, I don't know if it's sad or good news. Do you know the story of the salesman from England a hundred years ago or something like that, that went to Africa to sell shoes?
01:10:52
Speaker
Two salesmen. You don't know the story? So two salesmen from a big shoe company were sent to sell shoes in Africa to do a market study. And the first one, when he went back to the UK, said, oh, it's terrible. Nobody wears shoes. The market is zero.
01:11:12
Speaker
And the someone will say, oh, huge opportunity. Nobody will. Nobody will choose. Yeah, exactly. Yeah. Yeah. Yeah. So nobody, there is nothing on the internet about data oriented programming. If you Google data oriented programming, you will find only my stuff. Yours is the first. There is no Wikipedia entry. There is no articles.
01:11:34
Speaker
I found the guy that invented the world data-oriented programming, someone named Eugene Kuznetsov. He was kind enough to discuss with me on Hangout a month ago. And he invented that in 2002, so before closure. And actually he made a patent of it. And he built a company called Data Power that was sold to IBM.
01:12:03
Speaker
Um, so that's where it's all going to get sued. Probably. And then you have that invented design, which is a patterns from the gaming industry. Uh, where the goal there is to improve performance. So it has nothing to do with what we are talking about. You have data driven programming, which is the ability to express logic as data.
01:12:33
Speaker
But it's not what we were discussing today. And the topic of representing data is data, which sounds so natural. It has no cover on the internet. Only enclosure. If you Google for data on the programming after the mining marketing stuff, you will find an article from Cognitec that's enclosure is great because it's data oriented. That's it.
01:12:59
Speaker
Oh, nice. So you found something that is not there on the internet, which is pretty rare these days. Yes, yes. And not in collective psyche. What do they call it when you get like one response from Google? The Google flop or something? Or the Google? It's a special phrase when you put in normal English words and you get back one result. Wow. I didn't know it was possible.
01:13:28
Speaker
Well, it used to be, I think it's less and less possible now, but there's a special name for it, like a Google or something. Okay. Listeners, please phone in, you know. Yes. Call this number. No, not call, write to us. Oh yeah, write to us, write to us. Postbox number, something. We read every letter, by the way. So please do send, you know, all the fan mail, you know, it basically takes us, I think,
01:13:58
Speaker
At least two hours of my day reading through all the fan mail and responding to them personally. And we do send autographed stuff as well back to people. So if you write to us. Sealed it exactly. Especially with COVID times, it's very valuable. So what do you guys think about the question that I asked us about namespace keywords?
01:14:24
Speaker
I think it's yes. One of us should say yes and one of us should say no. Okay. Well, see, the thing is- And I'd say maybe. I'd say maybe. Yeah. I think I'd say yes, but not inside. I think we find this problem at work. I guess you find the same thing as well. Sometimes you have, like in a spec, you have all these namespace things where you just say,
01:14:53
Speaker
colon colon foo and of course it's a very convenient that it you don't have to type out you know Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah you know that would be very tedious so so that's really good but
01:15:09
Speaker
It's kind of then annoying to like use them outside of closure. It's a mess, you know, but if you have like, like in the atomic schema, you have like entity slash foo, then it makes sense. You know, I think that's that could be okay. I think and I think you can. So I'd say one is like internal
01:15:28
Speaker
like convenience, and the other one is a bit more structural for proper managing data in a good way, which is like around entities. And I'm a fan of that. My view on that is that as long as your namespace is only containing data, then the namespace keywords make sense. Because if you have the
01:15:48
Speaker
If you have the namespace keywords representing data, and then you have functions that are operating in the namespace, then you're essentially trying to encapsulate those things in one place, right? Then your namespace, if you squint really hard, it looks like a class again. Yes. In Java, so. We use that kind of approach for specs actually. So we have like specs for particular types of things using namespace keywords. And it works quite well. I don't think that namespace in the sense of closure namespace.
01:16:18
Speaker
but I would say a fully qualified prefix so that the field name is unique. And I think that it's an inherent part of data on the programming because it's like the chicken and the egg. Where do you start? Do you start from a map and the map has several fields? Or no, you start from a field and the map aggregates fields.
01:16:46
Speaker
And I think that in the data oriented programming approach, we start from fields. Each field lives on its own, has its own right to live. And the same field could be part of a hundred maps. You could have a user, you could have an email user, you could have a product user, you could have a, so.
01:17:09
Speaker
But then, if the name of the field is short, with no context, then it's meaningless. So I think it's a logical consequence, or it's the next step. And I think that's the reason why Rich Icky spends so much time to explain that the field should be decomplected from the maps, and you should spec them before you spec the map. So if a user email
01:17:38
Speaker
is an email, then it has a semantics of an email. No matter if it's in a map, a big map. Yeah, well, yeah. Yeah, because I mean, you know, you can have like a input map and output map. You can have all kinds of transformation maps that deal with users and to have it as just one map is mental. GraphQL, they don't have that.
01:18:02
Speaker
But isn't that like the whole like, you know, the concept of an atom, you know, that's from a data perspective, that's what that's what an atom is, isn't it? It's a field, you know, it's like the lowest level, the lowest use of. You don't mean to close your atom. No, no, no, no. Yeah, I mean, they're also in Lisp, you know. Yeah, yes. But in statically typed languages, fields don't exist.
01:18:30
Speaker
at runtime, a field is just an offset in a class. It's just an offset, and it's a tragedy, in a sense. That the most important piece of the information, which is the name of the field, it fades away during compilation. And by the way, that's half true, because, for example, in Java, they are available through reflection. And every JSON serialization library uses reflection.
01:18:59
Speaker
There is no other way to serialize. There is this Google library, not the one that we use in Close, not the Jackson. There is JSON, Google JSON, and they use reflection. You pass a record or a class, and you get back a string with no annotation, with nothing. It's full reflection. So even in Java, which is maybe the most static language in both sense of the world, they acknowledge the need for one, like we talked before, data classes or records.
01:19:29
Speaker
and reflections or having access to fit names. Cool. So I think we- Nice teaser to end on there.
01:19:38
Speaker
Yeah, exactly. So we covered at least the gist of your book, and I'm pretty sure I think people, even for people who are familiar with closure, right? I mean, it makes sense to have a go at it, to understand it in a much more holistic way, or maybe the fundamental way. So I think it's a really good idea to write
01:20:00
Speaker
write these concepts down to communicate them better, as you said in the beginning. So it's pretty awesome. And obviously, I haven't read the book. As you can see, I'm not a reading kind of guy.
01:20:14
Speaker
But as soon as your book is published in full thing, then I'll certainly give that a try. And so it is available as a Early Access publication right now, right? Manning Meet. Yes, it's called Meet Manning Early Access Program. And if you just Google it, you'll find it.
01:20:40
Speaker
And if you go to my Twitter profile, you will get a discount code and you feel really want to buy the book and you want to write a review and you don't have $20 to spend, you can send me an email and I will offer you a book.
01:20:57
Speaker
That's awesome. That's very kind. Do the thing I like about your book. I've skimmed it. Like I say, I haven't read it fully yet, but I've had a skim through of it. What I like is that you have a very conversational style in the book.
01:21:12
Speaker
you know, is that it's a kind of like two colleagues speaking to each other, which makes it very readable. I think, you know, it's a kind of like, we didn't really speak about that, but I think you've got a nice, nice writing style. You know, it's kind of, it's very casual. It's very, but it's sort of a one colleague challenging the other colleague, you know, which is, which is nice. You know, I think that people, people will, will find it very approachable and very, very kind of relatable, you know, in that sense. Yeah. The only problem is that I became a schizo friend since then.
01:21:46
Speaker
So it's more Plato's dialogues rather than regular books. You know, people actually talking in the interlocutor and everybody discussing stuff, which is pretty awesome. Nice. So go check out the book and we'll put the link in the description, obviously. And then also a big shout out to Yohannadhan for coming back again and sharing all this awesome knowledge. Thanks a lot, Yohannadhan, for joining us again.
01:22:11
Speaker
And we'd love to have you back again in, I don't know, in two years. Who knows? You'll find another thing that is not there on the internet yet, and then you write a book about it. Okay. That'll be awesome. So that's it from us. And yeah, and stay safe and we'll be soon back with yet another awesome episode. And thanks again, Yohanathan. Thanks again, Yohanathan. Yeah, it's really good. Excellent stuff.
01:22:38
Speaker
Thank you for listening to this episode of Deaf and the awesome vegetarian music or the track is Melon Hamburger by Pizzeri and the show's audio is mixed by Wouter Dallert. I'm pretty sure I butchered his name. Maybe you should insert your own name here Dallert.
01:22:55
Speaker
If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us, then do check us out on Slack, Closureion Slack or Closureverse or on Zulep or just at us at Deafened Podcast on Twitter.
01:23:24
Speaker
Enjoy your day and see you in the next episode.
01:23:51
Speaker
you