What is abstraction?

We use the term 'abstraction' all the time. But what does it mean? If it's such an important concept, we should have a clear idea of its meaning. In this episode, I go over two related definitions from two important sources.

Transcript

Eric Normand: What is abstraction? What is unabstraction? This episode, by the end of it, I hope to get to the bottom of this common term. Probably won't get all the way to the bottom.

My name is Eric Normand. I help people thrive with functional programming. This is an important topic. It's a term we use all the time. I hear it used. I read it.

People say, "Oh, I built this abstraction. Here's an abstraction. Let's make an abstraction." Do we really know what it means? I think most of the time we use it incorrectly. That's why I wanted to start researching it and decided to make a little episode about my research.

I recently listened to the CoRecursive Podcast. It's another great functional programming podcast by Adam Bell.

He does interviews. He had on Hal Ableson, who was the co-author of "Structure and Interpretation of Computer Programs." Adam asked him a lot about the origins of the book and why it was important because it's, I don't know, 40 years old now, almost.

He said something really interesting I didn't know which was, at the time that it was written, most programming books were like, "OK. Here's your data types and here's your syntax."

Their book, "Structure and Interpretation of Computer Programs," does a little bit of talk about data types and stuff, and it really starts pretty early with abstraction and what does it mean.

This idea that computer programs are written for people to read primarily, that you're building up, you're composing up abstractions. It just starts really early with that.

That was new. At that time people, weren't using the term abstraction quite so much.

I got curious. I've done research before about what abstraction means. When I say research, I'm talking about light, light research.

I look it up on Wikipedia. I ask my friends what they think it means. [laughs] It's not heavy duty research.

Sometimes, you have friends that have good insights and tell you exactly what to read. That happens to be the case. Let me get into this.

The way I hear people use "abstraction" all the time is they'll say, "That's the wrong abstraction or I'm building an abstraction." What they mean is they're composing up pieces from their language that they've built already into something new. They're building a class or a function or something. They're calling that an abstraction. Are these really abstractions?

"Structure and Interpretation of Computer Programs" defines abstractions as naming and manipulating. It's not about the composition. It's about giving that composition a name and being able to treat that composition as a unit, as a thing that can be further used in your program.

It's a way of ignoring how the thing is made. You're giving it a name. Now, you don't care where it came from. You're just going to refer it by name. It's a way of ignoring that origin.

In the book, they also have a quote from John Locke about abstraction. In that, John Locke talks about different ways of understanding an idea. One of the ways is to take that idea by itself completely out of context not related to anything else and just look at the idea alone. That's what John Locke calls abstraction.

It's this ignoring the context. It's removing it from its concrete origins. Both of these are kind of similar. You can see that maybe that the [inaudible 5:02] definition is a refinement of this definition for use in programming and not just as thinking and philosophizing as John Locke was doing. They're all about reification.

We take this thing that has some meaning in a context and we take it from that context so that we can look at it alone. We take this function or this class that we've built out of parts. We put them together and now we're just going to ignore where it came from and just refer to it by name and now manipulate it based on its name. Totally removing it from context.

This is the kind of abstraction that you might think of like something is very abstract. It has no context. It has no real world part to it. I'm just talking about in the abstract outside of the context.

There's another definition. There's a different definition. Zach Tellman is a Clojure programmer, pretty well known Clojure programmer. He's written a book called "The Elements of Clojure."

To write that book, the research — better research than I do let me tell you — he read a lot of books to put this book together. He was looking for a definition of abstraction for that book.

He eventually discovered and settled on Barbara Liskov's definition, which he says is the best one, so clear. After searching and searching, this was just like, "Yes, that's it." Why couldn't I formulate that? She has come up with such a nice definition of it.

I'm paraphrasing. I don't know the particular words she uses, but it's basically treating two different things as if they were the same. You're ignoring the differences and just treating them as if they were the same. This is stuff like modularity.

I have these two different modules. They're different, but they have the same API so I can swap them out. We do this in the real world, the whole idea of interchangeable parts. "Oh, this piece broke on my vacuum cleaner. I can just order another part and it pops right in." It's a different part. It is a totally different part.

It's not the same part, but it still works in there because it's made to have the same interface as the other part. They might even be made on the same machine, but they are different. We're ignoring those differences and using them like they were the same.

This is where we get polymorphism from. Two classes that implement the same interface are supposed to be interchangeable.

Also, you see this idea of reification, that you can start talking about the interface itself and not the particular instances of that interface.

Reification is coming up in both. You're able to manipulate the abstraction as it is without caring about its origins. That's kind of a reification. You're talking about it and manipulating it by name.

This other kind of reification where the thing that is similar about them, the interface between two things, is the thing you're talking about. Both are about reification.

Looking at these two definitions that are...they're different. One is more primarily about reification, this naming and manipulating. I have a whole episode on reification.

Reification basically means making something real so you name an idea and now you can talk about the idea as if it were a thing, even though, it was just an idea. That's reification.

Philosophers do this all the time. They make an idea real. They flesh it out. That's reification. We do that in computer programs by saying, "Let's make this relationship first class."

A person has a bike. I don't know of that's a good example, [laughs] but you can make that first class, like a possession. It's a thing now.

The second definition is more about ignoring differences between two things that are different. In the first case, you just have one thing and you're ignoring something. You're ignoring its origin, how it was created.

Then, the second thing, you're talking about two different things and how they are similar. How they are similar becomes reified. They're very different. Neither of them really is how we use the term. It's not about building something up and calling that an abstraction. It's about something else.

It's about this idea of treating two things the same, so in the sense of like, an algebraic property is an abstraction, because, as far as associativity goes, we are treating addition and multiplication the same. They're both associative so we have this thing that ignores the actual operation and just says these things are the same.

At the same time, we've named it and now we can manipulate it as a thing. That is the other definition of abstraction.

I don't think we have gotten to the bottom of this. I think that we are closer. I think I have a better idea of abstraction. I hope you do, too. I'll just recap really quick.

We often say build an abstraction or have the wrong abstraction and really we're not talking about an abstraction. We are talking about something we've composed up. It's more like a concretion. We've taken a hash map and mashed it up with a vector and now we're calling that an abstraction. It's not an abstraction.

The abstraction is naming that thing and being able to manipulate it or seeing that we can treat it the same as some other thing and doing so. Treating them the same even though they're different.

All right. If you've enjoyed this meandering explorational episode...I have a feeling some people would really like this and would want to discuss further, especially since I haven't really come to any firm conclusions or anything useful. Probably get more feedback on this one than I get on most episodes.

Well, if you liked this one, you can find all the other episodes at lispcast.com/podcast. There you'll find audio and video and text versions of all the past episodes.

You'll also find link to subscribe and please do so that you get the new episodes and links to find me on social media so that you can get in touch with me with all that great feedback, all those great thoughts that you're having right now. I'd love to hear them.

This has been my thought on functional programming. My name is Eric Normand. Thank you for listening and rock on.