What is the benefit of data orientation?

Data orientation allows freedom of movement between layers of meaning. Each interpretation adds a layer of meaning. If the data were hidden, we would not be able to freely interpret it how we want. In this episode, we explore an example of what it means to move up and down the layers of meaning.

Transcript

Eric Normand: What is the benefit of data orientation? In the last episode, I went over what data orientation is. Now, we're going to be talking about its benefits.

By the end of this episode, I think you should have a really good idea of why data orientation is useful as a programming paradigm, programming style process. I don't know what it is. My name is Eric Normand, and I help people thrive with functional programming.

Data orientation — just a quick recap — means programming with data. I'm going to amend it a little bit, and I am going to say at all levels.

I'm going to cut to the chase. The benefit is freedom. It's freedom to work at the level you want to work at, the level of meaning.

What do I mean by level of meaning? Let's imagine we have some JSON. It's a map. It's got some string keys and some string values. Some of the values are maps as well. There's arrays in there with some numbers. It's a JSON.

Now, let's go down a layer of meaning. Down like, let's un-interpret this. We're going down a layer of meaning.

At a lower level, this is just characters. We took some characters, and we parsed them into JSON.

JSON is really like a syntax for how you represent maps, arrays, and strings, etc. It's a syntax. It's really characters one level down. Characters, if you go down another level, are a sequence of bytes.

That those bytes require interpretation to turn them into characters. Then the characters require interpretation to turn them into JSON. These are the levels I'm talking about, the levels of meaning.

We're back at JSON. If we interpret again, we go up another level. We look into the JSON. We see it has information that makes it pretty clear that this is an HTTP request.

It has a URI. It has a server, host. It's got a request method, stuff like that. It's an HTTP request.

Let's take this HTTP request. It's still JSON. Let's take this HTTP request, and let's interpret it. Go up a level.

The way you usually do when you interpret an HTTP request, one thing you can do is you can route. You can look at the path and figure out like, "What is this HTTP request supposed to do?"

We see that it is an update to the user settings. The users have settings in our system, and this is a post to /user/settings. We can interpret this and say, "Wow, this is a request to update the user settings."

Now, if we look, if we interpret it again, we're going up another level of meaning. We're going to see that you look in the body, and it's a set password. This is trying to change the password of this user. Let's stop there.

We got all these levels. I'm going to count them. One, two, three, four, five, six. We've got over six layers of meaning here.

This is the benefit of data orientation that you can move freely. You have the freedom to move up and down the layers.

I'm interpreting. I'm going, again, adding meaning. I'm adding meaning. I'm adding meaning. Then I can go back down.

Even if I'm at the highest level we got to, which is, "This is a request to set the user's password," I could still take that and go back down to bytes. I could take it and serialize it over the network. This is a freedom that we have.

If you were hiding the data, you wouldn't have that freedom. You don't know how to go. You'd have to invent in the whole API to move along these levels, these layers of meaning. This is the benefit — the freedom of moving up and down. This is going to be a quick episode.

Let me recap. Data orientation means programming with data at all levels of meaning. The benefit is freedom, because you're working with data at all levels — moving up and down, interpreting, even going down as a kind of interpretation.

If you say, "I've got this update user settings request," now let me treat it again like an HTTP request and get this header out of it. Or let me treat it, again, like JSON and I'm going to just get the keys from it, which is something you can do with JSON, with a map. You can get the keys.

I want to note also that some of these interpretation levels had a change of type. When we went from byte stream or byte array to string or character array, that was a change of type. Then when we went from characters, we parsed those, and we turned it into JSON. That was a change of type.

Then some didn't have a change of type. When we went from JSON to HTTP request, it was still JSON. We didn't put in a new type. It's the same type.

We didn't change it. Now, we're going to get to the details of this in the next episode, but just note that.

Let's recap. We had six levels of meaning there, and we were able to move up and down between them. At any point, we can treat it like JSON and serialize it to a string.

Then take that string, send it over the network. It's going to get turned into bytes, into packets. There's another kind of interpretation you've got there.

In the next episode, we're still talking about data orientation, but I really want to answer this question of types and whether you can use types with data orientation.

If you like this episode, you should subscribe. You should go to lispcast.com/podcast. You will find links to subscribe, also to get in touch with me on social media. You'll also find all of the past episodes, including audio, video, and text transcripts of all of them.

You can subscribe however you want. If you want the videos, you can subscribe on YouTube. If you want the audio, you can subscribe in iTunes or whatever podcast player you use. Or you can get the RSS for the text if you like it that way.

This has been my thought on functional programming. I'm Eric Normand. Thanks for listening and rock on.