Yehonathan Sharvit joins the Jabber crew to discuss Data Oriented Programming. Data Oriented Programming is a way to reduce complexity by managing the shape of the data before we send it over the wire. Rather than managing data you send between services in class hierarchies, you focus on the data's meaning and manipulate it so the data it includes updates to your datastore like Redux and then cascade changes from your data.

Special Guest: Yehonathan Sharvit.

Sponsored By:

Gifting is hard. This isn't news, but what might be news is that you can now send beer, wine, and spirits right to your friends and family with Drizzly, the go-to app for alcohol delivery. Save time shopping, save money comparing prices across stores, and spend more time sipping with your gifties. Now that's good news. Download the Drizzly app or go to drizzly.com. That's D-R-I-Z-L-Y.com, and get your favorite drinks delivered today. Must be 21 plus, not available in all locations.

 

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. I'm coming at you live from that awesome underdust treadmill I've been talking about. 

CHARLES MAX_WOOD: Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. I'm jealous of AJ. 

CHARLES MAX_WOOD: I know me too. Steve Edwards. 

STEVE_EDWARDS: Welcome Portland.

CHARLES MAX_WOOD: I'm Charles Max Wood from DevChat.TV. Quick shout out if you want to get coached on how to become a Dev Influencer. Two links, one of them is DevChat.TV slash hero. Fill in a little information, we'll do a strategic call, figure out what you need to do next and see where things go from there. The other one is I'm starting a podcast. It's gonna be called the Dev Influencer Podcast. You can find that at DevInfluencers.com and I'm gonna be talking about a lot of the same things I'm doing in the accelerator. So there you go. We have a special guest this week Yehonathan Charvit. I hope I got that right. 

YEHONATHAN_SHARVIT: Hi, I'm glad to be here with you guys. I hope we'll have a great time. 

CHARLES MAX_WOOD: Yeah, we usually do, often at AJ's expense, but we do. Right, Steve? 

STEVE_EDWARDS: Absolutely. 

 

When I went freelance,I was still only a few years into my development career. My first contract was paid 60 bucks an hour. Due to feedback from my friends, I raised it to 120 bucks an hour on the next contract. And due to the podcasts I was involved in and the screencasts I had made in the past, I started getting or even heard of who wanted me to do development work for them because I had done that kind of work or talked about or demonstrated that kind of work in the videos and podcasts that I was making. Within a year, I was able to more than double my freelancing rates and I had more work than I could handle. If you're thinking about freelancing or have a profitable but not busy or fulfilling freelance practice, let me show you how to do it in my Dev Heroes Accelerator. Dev Heroes aren't just people who devs admire, for clients who know, like, and trust them. Let me help you double your income and fill your slow downs. You can learn more at devherosexcelerator.com. 

 

CHARLES MAX_WOOD: So yeah, so data-oriented programming. Like, what is that? Let's just start out with the basics, right? 

YEHONATHAN_SHARVIT: Yeah. So first of all, I think it sounds cool as the title. It's attractive. Everybody loves data. Everybody loves programming. So why just not simply make you an attractive name that aren't in programming. So that's the most exciting programming paradigm that you could imagine. 

CHARLES MAX_WOOD: I know, right? 

STEVE_EDWARDS: It can't be good if it doesn't have a good name. 

YEHONATHAN_SHARVIT: Yeah. 

AJ_O’NEAL: So this, the question here, because when you talk about it, like a buzzword data sounds like hashtag, follow the science kind of thing. You know, like we're going to, we're going to look at the, the, the analytics and the analytics are going to tell us how to orient. Is that, is that what it is? Or is it just like how we're looking at JSON objects. 

YEHONATHAN_SHARVIT: Yeah, we'll figure out. I think as the discussion goes, we'll distinguish between data oriented programming and other programming paradigm that either are similar or just have a similar name. Like for example, that oriented design, which is almost the same name, it has nothing to do with that oriented programming. 

CHARLES MAX_WOOD: Gotcha. So yeah, so what are we talking about here then? 

YEHONATHAN_SHARVIT: Okay, so we are talking about a way to reduce complexity in programming and not programming in general, but programming in the context of information systems of web services, web servers, front end applications that deal with information. So typically a web service that fetches data from another service or from the database, manipulate it and send it back to the client over HTTP and JSON. For information system like that, there is a way to reduce complexity. And this way is called data-oriented programming. 

CHARLES MAX_WOOD: Well, I like reducing complexity. Go ahead, AJ. 

AJ_O’NEAL: So break that down a little bit more. The first thing you said was, before you put it in the database, we're gonna do what with it? 

YEHONATHAN_SHARVIT: Let's say after you fetch it from the database, you do a small manipulation, you rearrange the shape of the data, and you send it over from the wire. 

AJ_O’NEAL: Okay, so we're doing, this sounds almost backwards, the shape of the data is one thing in the database where we're transforming it before we send it over the wire. So what, tell me more, what defines the difference between an orientation in a database and an orientation over the wire? Or maybe even what over the wire means in this case. 

YEHONATHAN_SHARVIT: What I mean is that data-oriented programming is appropriate when you need to build a web service that fetches data from the database and sends it over the wire. And if, I don't know, if we compare it with a, let's start by comparing with the object-oriented approach where every piece of data that you consume is modeled with a class, for example, in let's say in Java or C sharp or even in JavaScript. And the claim is that if you define classes for just representing data, you're going to end up with those giant class hierarchies that mess up in your system. And make it really hard to understand what's going on because there are lots of layers and intertwining relationships and connections and inheritance and dependencies while what the application does is only to manipulate data, to consume data and to pass over data. So I don't know what kind of Node.js application, let's say you like to write, if you go for a, let's say functional JavaScript or an object oriented JavaScript. So depending on what you're going to answer, I'm going to tell you what's the difference and the benefits. 

AJ_O’NEAL: Well, I think most people think that they're writing functional JavaScript because they get told that it's functional. I think most people actually end up writing something that looks rather object oriented. 

STEVE_EDWARDS: Or rather, or shall we say dysfunctional JavaScript? 

AJ_O’NEAL: I don't know what the heck would you classify react as? Cause I know a lot of people are using that these days and I don't know if that falls into either paradigm. That's just kind of a, like a strange, I guess it is somewhat more JavaScriptic and that it's, it is very event oriented. 

CHARLES MAX_WOOD: Yeah. It's more reactive than anything else. Yeah. It's in and of itself. Yeah. It's, it's more reactive than in any other paradigm. 

AJ_O’NEAL: Let's assume the browser context. 

CHARLES MAX_WOOD: So but yeah, I mean, for the most part, when I talk about it with people, I'm talking to people about yeah, they're usually doing more functional programming with it. Not always. And they blur the lines a lot when they're dealing with data, but yeah. 

YEHONATHAN_SHARVIT: So in a TPE, when you write a front end application, do you use classes in JavaScript or only a object hash maps? What kind of JavaScript developers are you? 

STEVE_EDWARDS: That's a dangerous question. If we talk about what kind of developers we are. 

AJ_O’NEAL: The bad kind. We're the bad boys and girls. I personally tend to favor objects because. JavaScript is a very nice fluid language and anything that you could do with classes, you can do with objects. So I just kind of stick with one tool to rule them all. 

STEVE_EDWARDS: Yeah, I agree. You know, yeah. Objects, you can have arrays, you can have objects within arrays and arrays within objects and define different types. And, you know, that's, that's how I tend to kind of my data as well. 

YEHONATHAN_SHARVIT: What about, 

AJ_O’NEAL: I think that's kind of the way React is as well as you typically like they used to do the whole class syntax for the event management, but that really wasn't about the data. That was about the event management and the data goes through as plain objects, it seems. 

YEHONATHAN_SHARVIT: Yeah. What about the store? If you are in the React application, do you like Redux or your more MobX or different approach? 

STEVE_EDWARDS: As a Vue developer, I use, you know, by default, I use Vue X, which is, you know, Vue 2 version of the store. 

CHARLES MAX_WOOD: Redux, Redux pattern. 

STEVE_EDWARDS: Yeah. Redux for React and so on. Now with VIA 3, we're supposed to be able to, with the new composition API, we're supposed to be able to get by without a store using their API. But I haven't delved quite into that in a lot of detail yet. 

YEHONATHAN_SHARVIT: So Redux, the way I understand it, is really data oriented in the way that you have the whole data of your application stored in a giant nested hash map, right? And what you do in order to manipulate the data is just write pure functions that manipulates part of the data. And the framework Redux will figure out how to update this giant map and then React will figure out how to rerender on the screen, on the browser. So right now I'm not talking at all about view layer or the rendering layer, I'm talking about the data. And Redux as a pattern is really what I mean by data oriented. And in a sense, data oriented programming as a paradigm is a formalization of the principles behind Redux and with a small refinement. And once those principles are articulated formally, we can apply them to other environments, like to the backend or even to other languages. But before we do that, let me tell you what are the principles of data-oriented programming. And then as a reader, I will ask you what principles are inherently applied in Redux and what are not applied in Redux. So principle number one is that we separate between data and code. And that's where we break object oriented. We don't encapsulate data inside classes. So the data lives in data objects and the code live in functions, static functions, no function with state. So I guess that this one is easy for you guys because you say that you don't use objects, but even using the lexical scope is not, is forbidden in data-oriented programming. Because when you use lexical scope or the closure in JavaScript by accessing, you know, variables that are passed in the constructor, you hide data and you encapsulate data inside an object, inside a behavior. This is principle number one. Principle number two is that you represent data as data not as classes or you represent data with generic data structures. You could say JSON, basically, primitives, uh, arrays and maps. And in some languages, we have more collection like sets, queues, stacks, but usually maps and the race cover 90% of the, of the use case. So that's principle number two. What does it sound so far? 

AJ_O’NEAL: Normal. 

YEHONATHAN_SHARVIT: Normal. Okay, great. Now, principle number three is that data should be immutable. And what do I mean by immutable? I mean that you are not allowed to change the value of field inside the HashMap. If you want, what you can do, you can create a new version of the HashMap that has a different value for the field. And that's the one that is not embodied in JavaScript by default or in Redux.

AJ_O’NEAL: Yeah, that's what I have a little bit of a hard time with because I realize that JavaScript's the only language that can run in a browser. That's not true anymore. We've got that. Oh gosh. I'm blanking on the name, the web. 

YEHONATHAN_SHARVIT: West end. 

AJ_O’NEAL: Awesome. That's it. Thank you. But for the most part, when we think about browsers, we think of JavaScript and I, I get a little frustrated when I see these patterns that seem to go against the design of JavaScript, it's not to say that JavaScript is a better design. It's just that sometimes when we have a pattern that goes against the way the design of JavaScript is like it or not, you add more complexity. You've got another layer and then you've got something that's potentially more difficult for other people to understand because they have to not just understand JavaScript, but then they have to understand this other layer that isn't part of the language. So what, what are your thoughts on that? 

YEHONATHAN_SHARVIT: Yeah. So that's the great insight, but before I address your objection, let me ask you, what do you think about when I say immutable data structures? What ideas come to you came to your mind? 

AJ_O’NEAL: Honestly, to me, it's a little bit like the same feeling as callback hell, where there's this idea that's it sounds really cool. You know, we're going to have asynchronous, we're going to have all these callbacks. It's going to be great. But then when you actually get into it, it's like, man, there's a lot of extra boilerplate or systems, things that I have to work around. And so when I think of immutable, I like a lot of the theory of it. But if I need something to be immutable, what I ended up doing personally is I ended up just doing a JSON dot stringify, JSON dot parse on top of it, or reverse those so that I know that I get a copy of the object because trying to work in JavaScript itself, it's not very comfortable to have those kinds of patterns for me. 

YEHONATHAN_SHARVIT: So you probably refer to using a library like immutable JS, who represents immutable data structure or another one? I haven't, I haven't actually used it, but I'm familiar with the concept. 

YEHONATHAN_SHARVIT: Okay. So, so I have great news for you. 

AJ_O’NEAL: Oh, good. 

YEHONATHAN_SHARVIT: They are basically, okay. Let's start with Joe. I wish JavaScript, at least JavaScript, the good part would have immutability by default, but that's not the case. So we could dream until tomorrow. It will never happen. So that's, that's one thing not putting joke aside, there are two ways to embrace immutability in JavaScript. One way is to use a library like immutable.js that provides fast immutable data structure. What do I mean by fast? Let's go back to your idea. Let's say you have a nested map, for example, your whole store with, I don't know, thousands of leaves, right? And you want to change one value in the immutable approach. If you're going to stringify and pass and then change the value, it will be very, very painful in terms of performance. It will take a lot of time, right? Because you have to clone. 

AJ_O’NEAL: Well, it depends. That can actually be quite fast in certain scenarios for very large objects that are multiple kilobytes. Yeah, it can, it can become expensive to use the stringify parse, but for small objects. I'd have to go back and look at the benchmarks, but my understanding is for small objects, it's pretty much the fastest thing you can do. 

YEHONATHAN_SHARVIT: Yeah. No. So it is if you don't use any magic tricks. But now I'm going to give you a magic tricks, two magic tricks. The first one is that there is a way to represent a hash map so that when you change a value in a hash map, no matter how nested it is, it's...All of one of complexity. It's like that no matter how many layers and how many leaves and there is a way and there is a smart guy named Phil Bagwell in the in the year 2000 or so That came up with this algorithm and it has been implemented first in closure Then in scala And then in java and in javascript and in every virtually in any language so facebook when they released immutable JS, they implemented this fast immutable data structure. And I'm going to tell you in a moment how it works. That is the magic. Now the magic trick number two. Have you heard about Lodash? 

AJ_O’NEAL: No, I haven't heard of that one. Is that a new one? 

STEVE_EDWARDS: Yeah, it's pretty brand new, isn't it? Yeah, it's just kidding. 

CHARLES MAX_WOOD: Nobody's using it yet, but hot stuff. 

YEHONATHAN_SHARVIT: Okay, what about Lodash SP? Have you heard about Lodash SP? 

AJ_O’NEAL: I've heard it, but I'm not familiar with its use. I'm assuming that it's they split off all the Lodash into individual functions and then have them apply immutability or return modifications as different objects. 

YEHONATHAN_SHARVIT: Exactly. 

STEVE_EDWARDS: But SP, is that like the ESPN version with the SP awards or is this different? 

AJ_O’NEAL: FP, FP, functional program. 

STEVE_EDWARDS: Oh, FP, functional program, sorry. 

YEHONATHAN_SHARVIT: Actually, if you go to the Lodash website, you will see in the top bar to the right, a link to Lodash SP. I never noticed this link until I started to write my book about data oriented programming. And what's super cool is that LODASH, for example, if you take a look at the set function to modify a value in a map or an asset value in a map, if you use the regular LODASH, it will mutate in place. If you use LODASH FP, it will create a new version of the map where the value has been changed. And the good news is that it's going to use structural sharing so that it's blazing fast and it doesn't consume too much memory. Similar to what Git does on every commit. When you commit a new commit in Git, you don't do copy your whole code base, your whole folder structure. You just make a change in the file that you want to change in the commit. So this technique is called structural sharing and it's implemented by a load hash. It allows you to cut the cake and eat it at once. Or no? 

AJ_O’NEAL: Have your cake and eat it too. 

YEHONATHAN_SHARVIT: Yeah. OK. So you can have the cake and eat it too. You can work with regular native JavaScript objects. And when you need to change the property in a map, instead of doing your trick of stringify and parse, you can use load-fp. And it's super fast and it doesn't take any memory addition. So for example, what you could do is that you could keep your store, no matter how huge it is, and keep different versions of the store on every user change, thousands or 10,000 of versions, and then go back and undo every change, go back to the history, like in Git, with no serious penalty in terms of memory or performance. 

AJ_O’NEAL: So I'm not sure if this is what you're talking about. But this sounds at first blush, this sounds like if it's modifying an array, it just makes a copy of the array with all the same elements. If it's modifying an element in the array, it creates a copy of the array with all the same elements except the one you're modifying. So 

YEHONATHAN_SHARVIT: shallow copy, that's the trick. 

AJ_O’NEAL: Well, yeah, but then you, not to say this is good or bad, but you have to be disciplined to follow the rule that you don't modify an object in the way that you typically modify an object in JavaScript. You wouldn't call dot name equals my new name. But isn't that the same thing as immutable JS? I thought that was kind of the same pattern it followed. 

YEHONATHAN_SHARVIT: No, because in immutable JS, you have to go back and forth between native JavaScript object and immutable data structure. So if you want to pass an immutable data structure to a third party library, you need first to convert it to a regular, to a native JavaScript object. If you use the load-ash approach that I just mentioned, you could live only with native JavaScript objects. And for implementing reducers, I think it's very powerful in Redux because you are guaranteed if you are disciplined that all your reducers use, modify the data only through load hash method and not directly with the dot name, dot property notation. Then you have the benefits of the immutability and you can go back in time, which is impossible in regular JavaScript. Cannot go back to previous state because the data has gone, has been modified. And it's not just about going back in time. You know, it just sounds cool, but it's, it's really evaporating tons. I don't know. Lots of bugs. When you you are disciplined enough to guarantee immutability, lots of bugs simply don't occur. You have an object in your hand, it's a value, it's like a number. When you have a number, X equals 42, 42 will never change. Even when you say X equals 43, the 42 is still there. So we have, when we are disciplined and follow the third principle of data-oriented programming, we benefit from that across the board, for all pieces of data. 

STEVE_EDWARDS: So if we could, let's, I want to step back a little bit, just to some more basic stuff in the immutable data objects that we're talking about. First of all, it sounds like we're assuming that immutability is good. And I'd sort of like you to explain why that is. Some people who aren't as advanced. And then I got another question after that. What is the benefit of immutable data objects? 

YEHONATHAN_SHARVIT: Okay, let me, I just, yesterday, I implemented a function called rename keys. So let's say you have a map with 10 properties and you want to rename some of the keys. So for example, ID you want to transform to user ID and product ID you want to change to the product ID. Okay, you could imagine a function that we see the two maps, one map with the data and the second map with the mappings between the old keys and the new keys. Right? Could you imagine writing such a function?

STEVE_EDWARDS: Sure. 

YEHONATHAN_SHARVIT: OK, so it will be a reduce, basically. You reduce over the second map, and each time you see a mapping, you replace in the original map the, you create a new property and you remove the old one, right? 

STEVE_EDWARDS: OK, I'm with you. 

YEHONATHAN_SHARVIT: So if you do that without immutability, it's going to be a pain in the ass, because you could remove a property that is going to be accessed by another mapping. So for example, if you decide to rename A to B, and B to C, if you remove B when you want to access it again, it's gone. And if you stick to immutability, you have the initial object left untouched. So the fact that you create a new object with slight modifications, let's say in the original object you have 100 fields and you want to change three of them, the fact that you guarantee that you don't touch the original object makes you 100% sure that you are not going to have bugs that might occur depending on the order you pass the key that you want to map. So that's one. 

STEVE_EDWARDS: Sorry. Okay, sorry, go ahead. 

YEHONATHAN_SHARVIT: So that's one example of bug that simply doesn't occur when you stick to readability. 

STEVE_EDWARDS: Okay, so now you, when you reduce function, you have two objects. How are you knowing when to access one versus the other? So you basically got old object, old object and new object. So you've run your reduce, you've created your new one, but you're saying you want to keep the old one around in case you need to access that original queue. Am I understanding correctly? 

YEHONATHAN_SHARVIT: Yeah, so if you go, let's say, if you don't use your mutability, what you probably are gonna do is to copy the object and then makes all the modification on the copy of the original object. But if you don't do that, if you don't do a defensive copy, you are gonna mess up with the original object and and having intermediate invalid states that might end up with a wrong result. Because you change the the fields or the name of the field temporarily. So usually what we do is we we copy the object and copying is might be expensive and it's not only about The performance it's more about the mind serenity that it gives me when I work only with immutable objects, I am, I don't know, half of the bugs that don't occur. So I prefer to stick to this discipline, even if it's a bit inconvenient. So that when I deal with data manipulation, I am free of bags or this kind of bag at least. And if you add to that concurrency, either in a multi-stranded environment or with callbacks, it's even worse if you don't have the immutability. Let's say you access, you have an object. And then you call a callback, like say timeout or fetch data from the URL. And then you access again, the object when the server give you the response. You cannot be, you cannot know that the object is the same because maybe it has been changed in another part of the event loop in JavaScript. While if you stick to mutability, if you have your object in hand in the lexical scope, you know, it's the same forever. 

STEVE_EDWARDS: So how does this fit in? You know, we're talking about not changing data. Okay. How about a real life use case where you do need to change the data? And I think I understand where we're going, but I just want to clarify. So let's say, you know, one of your standard, probably one of the most standard use cases on the web is recalling data in a form, changing it, and then saving it, okay? So you have, you pull out your data from your backend and you have your immutable map or whatever, you know, format you're storing your data in. You display it in your form, let's say you're editing a user profile which is a common occurrence, right? So you changed your data. So obviously now you're gonna create a new object because of immutability, right? And so you're gonna take that immutable object and send that back. So am I understanding that correctly? 

YEHONATHAN_SHARVIT: 100%. The trick is that it will be fast if you use either immutable data structure or low-dash immutable methods. 

CHARLES MAX_WOOD: Why is that fast? 

YEHONATHAN_SHARVIT: Because they leverage structural sharing. So that they don't do a deep copy of the object that you would do if you go with the naive approach that AJ mentioned before, serializing and passing back. 

STEVE_EDWARDS: So you're basically referring to the same object beneath the covers then? Or I don't understand. 

YEHONATHAN_SHARVIT: So for me, internally, it refers to part of the same object. But as a user, you don't care. As a user, it's like if it were a deep copy of the object. And that's the beauty of it. So when I use low-dash immutable methods, it works like if I were doing deep copies, but it is fast. 

STEVE_EDWARDS: So it looks to the user, at least from the development standpoint, that you're using a new object, but reality it's basically the same object underneath? 

YEHONATHAN_SHARVIT: Yes, yes. Exactly like in Git, when you commit a new change to Git, it looks like you have a totally new repo, right? That all the files are yours. But under the hood, Git is smart enough not to copy all the signs. 

STEVE_EDWARDS: Because it's all pointers. It's all pointers, basically. 

YEHONATHAN_SHARVIT: Exactly. It's exactly the same. But it's hidden from you. You don't care as a user. You don't care of the internal details of the tree and the path and the shine. All this fun stuff. 

 

Hey folks, if you love this podcast and would like to support the show, or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production. And you can go sign up at devchat.tv slash premium. 

 

CHARLES MAX_WOOD: Yeah. The operating systems do this too. The term is copy on write. And essentially what it does is when you start a new function, it only pulls things over when you change them. I mean, 

YEHONATHAN_SHARVIT: yeah, but it's actually, it's not copy on write. Copy-on-write is the older approach. 

CHARLES MAX_WOOD: Okay.

YEHONATHAN_SHARVIT: This approach is called either structural sharing or pass copying. And it's a bit smarter. 

CHARLES MAX_WOOD: But it's the same idea, right? 

YEHONATHAN_SHARVIT: Yeah. 

CHARLES MAX_WOOD: It's here's what's changed and it refers to the old thing for the rest. 

YEHONATHAN_SHARVIT: Yeah. But it was copying, right? You could end, you might, you end up with deep copying on right. 

CHARLES MAX_WOOD: Yeah. 

YEHONATHAN_SHARVIT: You, you know, there is zero penalty. You never do a deep copy and that's what Git does. Let me give you another example. Okay. I hope I would remember the detail. Do you know that in react there is. React decides to rerender or not, depending on if the state has changed, right? 

CHARLES MAX_WOOD: Yep. 

YEHONATHAN_SHARVIT: So let's say that the state has not changed, which is most of the time, the state, the state doesn't change or only slight changes to the state. But let's start with no changes. And React needs to figure out whether there was a change or not. How the re it's called the reconciliation algorithm. How does it work? So react holds pointers to the previous version of the state and the pointer to the current version of the state. And then it does a copy by value down the tree. Right? Now, if you tell React that you use immutable objects, you could simply compare by reference instead of comparing every node in the tree. And if the pointer has not changed and you use immutability, you are guaranteed that the state has not moved forward. And that's why it's also beneficial to represent the state with either immutable data structure or manipulate with immutable method. And then you can tell React, forgot the name of this method, should render or something like that, should we render or there is a function that React call you, call to ask you, should I render again the component? Do you ask, what's the name of it has probe change or something like that. And if you use immutability, you can implement it super fast because either the reference has not changed. And even if there is a change, you are gonna go down the tree. And again, if one subtree, the reference is the same, you are guaranteed that there is no change. So you don't need to go down the tree and compare every leaf to figure out that nothing has changed. And that's another benefit of immutability. And in my book, I illustrate how to implement a diff algorithm that received two versions of the state. Again, the state has a deeply nested hash map and compare or calculate what is the diff between the map. And when you leverage immutability, the diff algorithm is super fast because each time you encounter a node that has not changed, the reference is going to be the same. And if the reference is the same, you don't have the fear that maybe a property has changed without changing the reference which might be the case in regular JavaScript, right? You could have two pointers to the same object, but changes might have occurred to one of the properties. Even if you use schools or whatever, JavaScript doesn't predict it from that. 

CHARLES MAX_WOOD: Right. But if it's immutable, then if you check the pointer and you know that it's not going to change, then you can just check the pointer and know that it's the same. 

YEHONATHAN_SHARVIT: Exactly. Exactly. Again, like, like indeed, that's why, that's why, that's why this is fast. Because if a folder is the same between two commits, you know that all the files in the folder are the same. You don't need to check them. 

CHARLES MAX_WOOD: So I'm curious, what kind of got you to this point where you have these principles for data-oriented programming? Like what's your background? What kind of brought you to these conclusions? I mean, I'm assuming that there's some discipline around it that people talk about, but what's your story into this?

YEHONATHAN_SHARVIT: Yeah. So first of all, there is no, if you Google data with the programming, you will find nothing. 

CHARLES MAX_WOOD: Oh, okay. 

YEHONATHAN_SHARVIT: I mean, one month ago, you would have find nothing. And now you will find only, only my book and my draft Wikipedia article and the thousands of blog posts that I'm writing about it. 

AJ_O’NEAL: So is there not some other name? Because this feels like it's very similar to functional. And it feels like it's very similar to what I've called. Well, not that it's similar to, but it fits in with what I've called event-driven development. So is there another name that is, or some adjacent keywords? 

YEHONATHAN_SHARVIT: Okay. Let me address this question, but first I want to answer Charles' question about my story with the data programming. And it goes in the middle with my love story with JavaScript. So 20 years ago, I started the programming and I suffered so much because I had to program in C and C++ and it was a nightmare. I felt like I am a servant of the compiler and I have to fight so hard to tell the compiler what do I want and the compiler would never understand until I change my formulation and fix my code again and again and again until it compiles and then I had to figure out all the runtime bugs. So that's what that was my story between 2001 until 2009 and then God blessed me. And I was recruited by a company that were advertising company in the web. And I discovered JavaScript. And for me, it was a revelation. Suddenly I was able to tell the computer what I want without having to be a servant of the compiler with less words. I could express myself much in a much powerful way with the maps and the anonymous function and the, I don't remember if you called it Lambda back then but basically the JSON, the data manipulation and the function, no objects, no classes, no generic types, no hierarchy, no mess, no compilation, nothing, just writing what I want. And for me, it was really a revelation. It brought me back in peace to what I liked in programming. So that was in 2009. And then I used JavaScript in the front end. It was before Node.js. And in the backend, I use Ruby and a bit of Java, which I liked also, Ruby I liked also, but it didn't have the same beauty as JavaScript. You know, in Ruby you have GROK and Lambda and I don't remember, I don't know, five different things for anonymous function. And you never know which is the one and there are subtleties and slight differences between them. So it doesn't have the elegance and the simplicity of JavaScript. And I really love the group JavaScript, the good parts. So for me, JavaScript was really a great language and I was disciplined enough and I worked in a team that we were disciplined enough to never use this, only that. And we followed basically the patterns of Douglas Cropfoot. So it was really a fun period of my life. But, and I saw that would be the paroxys of my career. But then in 2013, four years later, I discovered Clojure and Clojure script. And that was like an illumination. Really. If JavaScript moved me from C++ to be 10x more productive, ClosureScript took me another, maybe not 10x, but 5x beyond JavaScript. And in Closure and ClosureScript, first of all, you have low dash inside. You don't need a third party library. You have thousands, not thousands, hundreds of data manipulation function as part of the language. And your language support data manipulation. So that was really awesome. And they have also the wrapper, which is a bit more powerful than the JavaScript console and macros so that you can extend the language when you want to add new features. And one thing that I didn't like with JavaScript is that it's so easy to write ugly JavaScript. And I used to say, I used to say JavaScript is really hard to write beautiful code. And in Clojure script is really hard to write ugly code. You could, but it's really hard. So by default, the JavaScript code will be a bit messy. It was before the module, et cetera. And by default, the closure code will be beautiful. And one of the reasons is because there is this extra step of compilation, which was new back in 2013. So between 2013 and 2020, let's say, for the last seven years, before last year, I asked myself, what is the thing that I like so much in closure? What makes me so much productive in closure? And I I took again riddles that a recruiter asked me when I wanted to apply for a job that I couldn't solve in any language. For sure in C++, like reverse single list or bullshit like that, or Dijkstra algorithm, and even JavaScript was hard. And suddenly in Clojure, I was smart. Suddenly my fingers, like a client list, my fingers found their way in the keyboard, and I was able to code data management algorithm like this using a high level function provided by Closure like group buy, frequencies, partition, and, and I built an audio engine in the client side, leveraging HTML5 audio for a startup that dealt with speech therapy. And it was lots of data manipulation and audio processing. And we, we wrote everything in ClosureScript and it was so easy and we are so productive as a team. So time has past and I ask myself and the closure community, what is the essence of closure? What is it that makes closure apart from other language? Is it the fact that it's a list? No, we have we have thousands of lists. Is it the fact that it's functional? No, there are so many functional languages, Haskell, OCaml, JavaScript in a sense. So what is it? And my answer is that it's the fact that closure as a language embraces that orientation and, and that's why I decided to write a book and to do research and to enumerate and formulate the principles behind that are in the programming so that developer from any languages could apply them in their own language. And for JavaScript, it's quite easy. Basically it's JavaScript with immutability, if you want to summarize, you know, in a one world. So that was a long answer to a short question, Charles. 

CHARLES MAX_WOOD: No, it's all good. And I love just the journey, right? I mean, that's the part of it that kind of gets me fired up is, hey, you know, I kept learning, I tried this, I did this, you know, I encountered these principles from this language and these ideas from this other place. And I realized that that, you know, that makes a difference in this way, right? So what were you asking, AJ? 

AJ_O’NEAL: I don't think I asked anything. 

YEHONATHAN_SHARVIT: Oh yeah, functional programming. 

AJ_O’NEAL: Oh, way back when. 

YEHONATHAN_SHARVIT: Yeah. So that's a tricky question because what you call functional programming in JavaScript is not what they call functional programming in Askell. 

AJ_O’NEAL: And Askell is the true mark, the true Scotsman of functional programming is Askell. 

YEHONATHAN_SHARVIT: Yeah, and there is a huge difference. Is that it's statically typed and it's a nightmare. It's a nightmare. Believe me, it's a nightmare. 

AJ_O’NEAL: Wait, why is it a nightmare? Because you get all that, that the matches, the matches are what make those languages great, isn't it comes from static typing, doesn't it? 

CHARLES MAX_WOOD: Don't play with me. 

AJ_O’NEAL: Oh, he's shaking his head. 

YEHONATHAN_SHARVIT: If you believe, if you believe that when it, if you believe this idiom, it compiles, let's ship. Okay, then go for it. But I don't believe it. 

AJ_O’NEAL: I have pretty good success with that in Go. 

YEHONATHAN_SHARVIT: Yeah, every time it compiles, you have zero bug? 

AJ_O’NEAL: No, no, but I'm saying, I'm not saying that JavaScript should be a compiled language. I think that JavaScript is a beautiful language in of itself. Oh, somebody just fired shots at me. Whoa, I got a duck down. But I do also appreciate particularly matches in compiled languages that support them. One of my favorite parts of Rust is matches. It makes me feel so safe. 

YEHONATHAN_SHARVIT: Yeah, you feel safe. 

AJ_O’NEAL: If I was gonna write a parser for something that was important, if I was gonna write software that needed to fly a plane, I would write it in Rust. And there's no other language that I would write software that someone's life depended on. 

YEHONATHAN_SHARVIT: You know what? Check me. What is the programming language used by the Boeing that crashed? I bet it's a statically typed language. 

AJ_O’NEAL: It's probably something like C or C plus plus, which is statically typed in the way that horses are unicorns. 

YEHONATHAN_SHARVIT: Anyway, we are not in this land. We are in information system, backend or frontend. And we deal with information that is sparse, that we don't know a priori what is going to be the shape of the information. And let me tell you this thing, I didn't program in OCaml, I mean, I program in OCaml, but I didn't program in Asken. And there is a tragedy, a tragedy, I'm putting a little bit of drama, but there is a tragedy in statically typed language, is that the names, the names, which is the most important part of our information. The name compiled away, the names compiled away. That's, isn't it a tragedy? You write your code, you have fields in your class, but at run time, the field disappear, it's just an offset in the layout of the class. 

AJ_O’NEAL: But that's the same thing in JavaScript. I mean, if you run your JavaScript through any transpiler, all the stuff disappears. 

YEHONATHAN_SHARVIT: No, no. 

AJ_O’NEAL: Yeah. You, you console.log anything from the Google API and tell me differently. 

STEVE_EDWARDS: Yeah, yeah. When I've seen kind of Spinal Code, it's all your beautifully named variables are A and B and C and D and they're gone. And the sad part is that that's one of the two hardest things in computer, well, two hardest things in computer science, naming things, cache and validation, and off by one errors. But yeah, you go to all that work and then it's gone. 

YEHONATHAN_SHARVIT: That, that, that. So how does it work? So you cannot stringify an object?

AJ_O’NEAL: So with many, with many APIs, you cannot, because they get the, the API details are internal. So for example, if you use Google login, like you want, you want to use the Google login button on a site, when you get back to the user object, you can call functions on that object. But if you console dot log the object, none of the functions that you actually use, which by the way are not documented, which makes this super frustrating. You have to find random examples, but none of the functions that you use are enumerable. And of the things that are enumerable, none of them have names that make any sense. They're like GA or AQ. So I realized that if you, if you have an object that goes all the way from an API all the way to a user form, yes, you can console.log that and it, and you'll see it. But the same thing is true in statically typed languages that have some sort of tagging system. So if you're going to use Rust. You're going to use, I'm spacing on the name for it, but the Serda, you're going to use Serda to interface with JSON and YAML and stuff like that. And all of your Serda tags are generated by the macro system and they're all there and the same thing with Go. All your tags are generated by the, the pre-processing system and they're there in the compiled binary. 

YEHONATHAN_SHARVIT: Yeah. But you cannot then add new properties. 

AJ_O’NEAL: You'd have to use a hash map and those probably aren't as efficient as they are in JavaScript because JavaScript has just-in-time compiler. So hash maps can get converted into memory efficient objects at runtime. Rust has something kind of like that, but it's not what we're talking about right now. 

YEHONATHAN_SHARVIT: So let's go back to JavaScript and front-end or backend. The fact, I think that the fact that we allow information to be extended and to add new fields on the fly without specifying them at compile time, it's huge. Imagine how your JavaScript experience would be if you had to specify everything at compile time and you were not allowed to add new fields. Every time you want to merge objects from different sources, you'd have to create a class for the different combination of the fields. So that's what they do in classic functional programming. And I think that's the reason why JavaScript was so successful because it made access to data a commodity and you represent data inside your code very similar to the way you represent data over the wire as JSON. There is no ceremony or or rappers or class or magic or whatever. 

AJ_O’NEAL: No, you got me sold for APIs, for stitching APIs together, it's hard to beat node. Yeah. It really is. 

YEHONATHAN_SHARVIT: And that's what we do. I mean, that's what we do. Or if you want to generate a form dynamically or a table when you don't know actually what are the fields, you need to either use reflection to figure out what are the fields, but then it's like cheating or I don't know what you do or do all kinds of annotations or magic or whatever. So, in that sense, data-oriented programming is completely different from functional programming because functional programming, the classic way is tactically tight functional programming. So, if you take JavaScript with the data orientation, oh sorry, with the data facility that it gives and you add to it the functional, the immutability the immutability part from functional programming, you get what I call data oriented programming. And that's for me, that's the best, the simplest way to write a program in the realm of information system, whether it's backend or frontend. 

CHARLES MAX_WOOD: All right. Well, I'm going to push this over to PIX. We need to start wrapping up, but this has been really interesting to dive into. And if people want to learn more, so you have your book on Manning, that's still in the early access program, correct? 

YEHONATHAN_SHARVIT: Yeah. We have the five chapters released out of 15. Okay. And in the book, there is I made something interesting. I, the book is formulated as a dialogue between a guy and a mentor named Joe. And all the book is just discussion between the two guys and they share code snippets. And there is a little story, the romance, not a romance, but a little story between the two. And it's really helpful for me to articulate my thoughts and to ask questions exactly like we did here in the show. I say something immutability is great in the book, Joe say it is great. And then the other card goes, no, why is this great? Like exactly like you guys asked. So I think it's a fun read with not jokes, but dialogues and stories. And it's an easy read. It's a really pragmatic book. It's not theoretical one. And all the snippets are in the book. There are lots of snippets that are in JavaScript, the simplest JavaScript that you can think of. No special features or anything. So you can read it in the restroom or on the beach. 

CHARLES MAX_WOOD: Awesome, very cool. All right, well, let's go ahead and do our picks and then we'll wrap up the show. 

 

This episode is sponsored by Sentry. Sentry is the thing that I put into all of my apps first thing. I figure out how to deploy them. I get them up on the web and then I run Sentry on them. And the reason why is because I need to know what's going on in my app all the time. The other thing is, is that sometimes I miss stuff. I'll run things in development, works on my machine. We've all been there, right? And then it gets up into the cloud or up on a server and stuff happens, stuff breaks. I didn't configure it right. AWS credentials, something like that, right? And so I need to get the error reporting back. But the other thing is, and this is something that my users typically don't give me information on, is I need to know if it's performing well, right? I need to know if it's slowing down because I don't want them getting lost into the Twitterverse because my app isn't fast enough. So I put Sentry in, I get all of the information about what's going right and what's going wrong, and then I can go in and I can fix the issues right away. So if you have an app that's running slow, you have an app that's having errors, you have an app that you're just getting started with, go check it out, sentry.io slash four, that's F-O-R slash JavaScript, and use the code JS Jabber for three months of their base team plan. 

 

CHARLES MAX_WOOD: Amy, why don't you start us off with the picks today? 

AIMEE_KNIGHT: Okay. Sorry. I've been very quiet, kind of debugging some prod issues and haven't been able to jump on too much. 

CHARLES MAX_WOOD: The conversations moved pretty fast too. 

AIMEE_KNIGHT: So let me, oh, I'm trying to look at my list here. Well, I'm going to go with, I don't think I've picked this yet. So ZS each tricks from the Twilio blog. And I will drop a link in the show notes. 

CHARLES MAX_WOOD: All right. Cool. Yeah. I've been using ZSH since Mac OS switched over and yeah, I like it. 

AIMEE_KNIGHT: Yeah. This is my first laptop that I have been using it to. It's pretty good. 

AJ_O’NEAL: Yeah. All are catching up, catching up. Using fish. 

CHARLES MAX_WOOD: I use fish. I just, I cook it. I eat it. You got it. 

AJ_O’NEAL: Obviously you can only use bash for scripting. That's a given. I would never recommend anything else out of all the crazy shells that are out there. Maybe PowerShell if you're a Windows guy, but Fish is the friendly interactive shell you deserve to be using. 

CHARLES MAX_WOOD: All right, AJ, do you have some picks? 

AJ_O’NEAL: Why, yes I do. So first of all, I've been talking about some lifestyle changes that I've been making. I feel confident enough about the treadmill now to pick it as a pick. I think I talked about it before. I don't think I picked it as a pick before, but it's a Urivo, Urivo, Urevo under desk treadmill. And I did a lot of searching for this thing because I'm a bigger guy. I'm over 260 pounds. So that rules out 95% of all treadmills that you're going to find that are under $2,000. And this one was about 400 bucks and it looks better than just about anything else I've seen out there. And I feel fairly confident that if I follow the instructions and oil it every once in a while and keep the, I put a little piece of plywood underneath of it so that the carpet doesn't, carpet doesn't interfere with the heat dissipation. I feel like this is going to serve me well. I'm enjoying it, using it a couple of times a week, really like it. The other thing, and this one's kind of a little bit here, a little bit there. So we have a britter water filter because we live in Pleasant Grove where the sewage water and the tap water are indistinguishable from one another and, and taste and smell. Well, not really the smell so much, but I actually haven't tasted sewage water. But anyway, it's pretty much gray water that they're just feeding back through the pipes at you. So we have a Brita filter, but the problem is the way that it's designed. Filters, the way filters work, if the water gets below the filter, then the filter dries out and the filter doesn't filter. And my wife is always using the water that's in there and then not refilling it. And then I go to refill it and I have to walk away by the time I come back and remember I wanted some water because it's so slow. It's all gone. So I got this three filter water filter and it filters water fast because there's three filters. The only problem is that the flavor is really strong. It seems like it puts a lot of calcium in there to give you that low alkaline slash mineral, whatever, but I couldn't find anything else. I was a little bit worried about it is a little strong. So what I do is I mix it like three or four parts this filter with one part Brita water. And that seems to be working for me pretty well. And then other than that, I'm going to do, so there's been a really positive response to our things you should know, things you must know JS series. So I am doing some, some Q and a and some live streams. If you are interested in that, please hit me up at underscore beyond code on Twitter or check some of these other links here. You can hit me up directly personally on Facebook or check out the YouTube channel that I'm creating for that. I would love to hear your questions, what you wanna know more about most. And I have AriaV intent to help you as much as I can. So please reach out to me. 

CHARLES MAX_WOOD: All right, Steve, you have some picks? So I don't have a thing to pick, but I figured that that in the past I've mentioned some of my favorite quote unquote dad joke sources. I think what I'm gonna do for cases like today where I don't have a pick is just to share a couple of the phenomenal dad jokes that are part of my collection. I have high standards as you'll be able to see, but I just thought I'd share a couple for today. The one that I shared on Facebook for instance is that, I come from a family of magicians. I have two half brothers. You get that.

AJ_O’NEAL: I actually laughed on that one, Steve. 

STEVE_EDWARDS: You were on mute, but I saw you laughing. So I appreciated that. And then another one, for instance, in the old days, excessive use of commas was considered to be a serious crime. It usually resulted in a long sentence. So thank you. Thank you very much. Make sure to take your waitresses to shows a day. Those are my picks for today. 

CHARLES MAX_WOOD: I think those might wind up being more popular than the beer picks that we had on the rogues way back when. All right. I've got a few things that I'm going to shout out about. I'm going to try and make it fast. And then, Yohanathan, if you have some things you want to shout out about as well, happy to hear about those. So the first pick I have, I'm not sure many people are aware, we do have a machine learning show and I've been kind of the primary host on that for a while, but it's starting, the panel is starting to fill up on that one, which is awesome. So anyway, you can go find adventures in machine learning just on devchat.tv and really digging that. In the interest of all of the self-promotion, we also have a Women in Tech show called She's in Tech. That one just started a couple weeks ago. So definitely go check that one out as well. And then I'm trying to think. So I have been doing the dev. I was calling it DevHeroes Accelerator, but I'm rebranding it all because I got devinfluencers.com for the domain and I like that. So I'm going to go with Dev Influencers Accelerator. If you're kind of stuck at senior developer architect level, you're trying to decide, okay, where do I go from here? A lot of people don't want to opt for management is typically what I'm hearing. Or it's, Hey, I'm just not learning anymore. I kind of help you walk through that. And there's a lot of focus for that on building a podcast, building an audience, having the conversations that lead you to the kind of growth you want, and helping you use that to network with people who are going to help you get where you want. There are also a few people who are trying to either build courses or freelance practice or things like that. And so using that also to kind of build up an audience that you can then help out in more depth by providing services and courses that are gonna  yeah, we've got some people that are getting ready to pull the trigger and start their podcasts. So keep an eye out for that. And then just on a personal note, I'm also gonna pick my doctor. I'm not going to tell you who it is, but I was talking to her today because I had a diabetes checkup. I'm diabetic and my diabetes numbers are really getting under control for the first time in a while just because I've been focused on it. And she's really been a great help there. But I asked her about the tension headaches I've been having and she told me to go get a massage and that made me happy. So I'm going to pick doctors who tell you to go get massages so you can tell your wife that the doctor said you need to go have a massage. Those are my picks. Johanathan, what are your picks?

YEHONATHAN_SHARVIT: It's kind of my love letter to JavaScript. Did you know that there are language evaluators for almost any language written in JavaScript so you could evaluate Ruby, Python, scheme, Lua, OCaml, Prologue, even BrainFac could evaluate in JavaScript. And a couple of years ago, I made a tool for making it super easy to embed code snippets into blog posts interactive code snippets where the author of the blog post would write a code snippet. And when the reader opened the page, the reader sees not only the code, but the evaluation of the code. And the reader can interact with the code and immediately is evaluated on the fly in the browser. So the tool is named Clips, K-L-I-T-S-E, and you can find it on GitHub. And if you are a tech blogger, you can find it on the website you might like it and make your blog post not only interesting, but also interactive. 

CHARLES MAX_WOOD: Awesome. All right. And if people want to find you online, I'm assuming you're on like Twitter and GitHub. 

YEHONATHAN_SHARVIT: Yeah. On Twitter, my handle is Viebel, which is a French word for life is beautiful after Roberto Benigni masterpiece 20 years ago. 

CHARLES MAX_WOOD: I love that movie. I lived in Arezzo where they filmed it for five months. 

YEHONATHAN_SHARVIT: Wow. Awesome. So that's. That's my handle. Yeah. 

CHARLES MAX_WOOD: Very cool. All right. 

YEHONATHAN_SHARVIT: I'm really thankful to JavaScript. Without this language, I would be in a different job today. I wouldn't have sustained programming with C++ or Java. I'm not, the way I like to frame it, I'm not smart enough to code in C++. 

AJ_O’NEAL: Anyone who thinks they're smart enough to code in C++ lacks wisdom. 

YEHONATHAN_SHARVIT: Yeah. I mean, they could- 

STEVE_EDWARDS: Is that your version of a proper?

AJ_O’NEAL: I'm just saying, if you're riding that close to the edge of the cliff, maybe you don't need to show off. It's C++ is a dangerous language. Like people die. Don't put that on a plane, please. 

CHARLES MAX_WOOD: All right. I guess we'll end it there. Don't put it on a plane. Thanks for coming. This was awesome. 

YEHONATHAN_SHARVIT: Yeah, great. Thanks for having me. It was a pleasure to be with you guys. 

CHARLES MAX_WOOD: All right. And with that, max out everybody. 

STEVE_EDWARDS: Adios.

AJ_O’NEAL: It's my line, Steve. 

STEVE_EDWARDS: I've been using, 

AJ_O’NEAL: let me say adios and then tell me adios. 

STEVE_EDWARDS: That's my line. 

AJ_O’NEAL: No, that's, that's totally my line. 

CHARLES MAX_WOOD: Wait, whose line is it anyway? Sorry. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c a c h e f l y.com to learn more.