What is an algebra?

Level 3 of functional thinking is all about algebraic thinking. But what do I mean by algebra? In this episode, I try to distill down the characteristics of an algebra and explore why algebras are worth developing.

Transcript

Eric Normand: What is an algebra? By the end of this episode you will know the two characteristics that make an API into an algebra. My name is Eric Normand, and I help people thrive with functional programming. So this topic, I'm bringing it up because this is very important for level three of functional thinking.

People have been asking me a lot of questions. Level three is all about algebraic thinking. They've been asking, "How do I develop that skill?" and "How do I get to level three, I'm at level two."

One of the things that you need to know is, what is an algebra? It's good to describe what it is. I've used the term before with some programmers who don't really understand why I would be using algebra. To them, algebra is this thing you learned in high school where you used a lot of letters instead of numbers and you learned to solve quadratic equations.

What does this software design, basically functional programming software design, what does that have to do with an algebra? What is an algebra as opposed to algebra? That's what I'm talking about in this episode.

What is an algebra from a software-design perspective, not from a math perspective? I'm not trying to define algebra in the mathematical sense. They have a much more precise definition. It's also used in several different ways. This is, I'm trying to get at what I'm trying to explain.

I'm not the only one to use this term. I've heard Alan Kay talk about it. They're like, "The point of software design is to find algebras." I'm not alone. [laughs] There's prior art from people who are way smarter and more certified than I am.

The first approach I'm going to take to explain this — I'm also working on my approach right now — is that Martin Fowler wrote a book about domain-specific languages, DSL. In it, he tries to explain what an internal DSL is. When you write one, it looks a lot like just a regular interface. A regular API, you might call it.

Why would you give that a different name? He talks about it. What he says, what his idea is — I tend to agree with this — is that, a DSL is an API, an internal DSL, not like you actually create a new grammar, you parse it, and stuff like that.

An internal DSL where you use the host language's pieces to make a new thing that it crosses some qualitative line and becomes very fluent. That's his word. Starts to get very expressive. You can say what you need to say without resorting to any tricks or anything like that. It's a qualitative measure.

It's still an API but you go from this push-button API — do this, do that — to a fluency, like, "Oh, I want my picture to look like this." It's a very similar qualitative change going from an API, an interface's set of functions, to an algebra. There are two qualities to it that push it over that line. It is a spectrum.

The line where it is is fuzzy, but pushing stuff toward the algebra side is a good idea. Here are the two characteristics. One, it's abstract. Two, it is cohesive. I'll explain what I mean.

When we're doing arithmetic, we're working with numbers — 4, 10, 15. We got these operations like plus, times, minus, divide. When we first start algebra class, we start to replace those numbers with letters. It can be confusing. A lot of students don't know what's going on. They want to know what x is, for instance.

Often you'll say, "Oh, wait, it could be anything," or you don't know what x is, but you still have to figure out how to continue solving the problem. We got this number. Number is an abstract concept but it's more concrete than a letter that represents some unknown number or all numbers. Put one number at a time but it could be out of all numbers.

It's a much more abstract concept. It lets you realize that there are things that are true about numbers and those operations that doesn't depend on the individual number. You could say x/x = 1, as long as x doesn't equal 0.

This is a statement where, at the beginning of algebra class, the beginning of the year, a student could say, "What is x? I want to check. If it's 3, then it's 3/3. That does equal one. I can do that. If it's 5, then it's 5/5. Yes, it equals one."

Eventually, by doing enough of these problems, seeing enough of these formulas, they come to realize, "OK. I don't need to know what x is. I can operate on the equation itself in this abstract, symbolic way and still do a lot of good, interesting work." That's what I mean by abstract. We're able to start replacing specific values with variables. We still have meaning.

I gave an example when I talked about level three, the three levels before. In level three, I talked about a video, "Algebra."

I could say something like, "If I concatenate video A with video B, I get video C whose length is the sum of the length of A and B." I'm starting to speak very abstractly. This is a true statement regardless of what A is or what B is, how it was created, what type it is, any of those things. It doesn't matter. I'm saying A and B in the abstract meaning anything, any video. That's abstract.

Now, cohesive, is required as well. Cohesive in the general sense means things go really well together. They are related. They work well together. I want to be a little bit more specific than that for my definition.

Yes, they have to go well together but they have to go so well together, that you can start to define relationships between them using each other. We have what we call, identities in math. They're basically equalities, their formulas with an equal sign.

They relate how addition relates to subtraction, how addition relates to multiplication, how multiplication relates to division. You start to actually have these formal definitions for how they interrelate. It's all expressed within the cohesive set of operations that you have. You don't have to go elsewhere.

One thing that happens in programming is we might come up with this really nice set of operations on a data type and then to define its behavior, we go outside that, we write some unit tests, and we get to do other things in the unit test.

Wouldn't it be better if we could say something like we say in mathematical algebra class. We could say A + B = C, means that C - A = B. We do that all the time. We will move the A to the other side of the equation.

C - A = B is derivable from the first one, A + B = C. This is setting up a little relationship that if one is true, the other is true. If we can start to do that, if our set of operations is cohesive enough, we can start to set up these equalities.

We can start to say, if I cut a video in half, or let's say I could cut anywhere, as I say I cut the video A into B and C, and then I concatenate them back together, it should be the same as A. That's like a little identity to say how they work, but in terms of each other very abstractly.

Then, you can start to do those kinds of symbolic manipulations that you do in algebra class. You can work on the equation, you can move stuff around and cancel things out, and move all the known to one side so that you can solve for the unknown.

You can do all those kinds of manipulations, not ever having a specific value for those variables. You don't have to have the value. That's the kind of place that we want to get in level three, where we don't even have to have the value.

We're able to reason on paper, on the chalkboard just moving stuff around and what we're doing is true. What we're doing is making progress toward whatever goal we have, but we never actually had a real value.

These things are so cohesive and abstract that we can start building on them and they're likely never to change like you could get it to the point where you've gotten rid of all the corner cases, it's a small API, and now you can compose them together to solve your problem.

You can compose a whole video editing suite out of these basic little operations, so you get those right and now it's just like a game of making the UI. That's the idea of level three, and that's what I mean by algebra.

There's two algebras that you're probably familiar with as a programmer. There is Boolean algebra, which operates on true, false, and it defines all these operators like "or" and "and," and stuff like that.

They're defined in terms of each other. You can define or... [laughs] or you can define in terms of negation and arrow. Double arrow can be defined in terms of "arrow" and "and." They're all interrelated. That is what makes it an algebra.

You can transform the not of an or, the negation of an or, into the and of the negation. It's like all these little identities that let you manipulate symbols. You don't have to know if it's true or false.

You can manipulate symbols and you can find an answer without ever having specific values. Another one is the relational algebra and this defines relations, which are like database tables.

They have two pools with name values in them and defines all sorts of operations on them. You can define some operations in terms of others, and you always are operating at this level of relations, which is another thing that I'm not sure of, but I'm going to bring it up.

Algebra is probably, I'm not sure, it's probably always with one or maybe a small number two or three very related types. Usually, it's one type. Like look at the relational algebra. It's one type, the relation.

Even if you have one row in your table, one tuple, that it's a relation of one. You have an empty relation, and you're always manipulating relations. Same with Boolean algebra. You're always dealing with true and false, a Boolean value, and you can't escape it because everything returns another Boolean.

Likewise, in the video-editing algebra, you're always dealing with a segment of video. You take a segment and another segment, and you put them together, now you have a new segment.

I think that's pretty secure, but I'm not ready to go there yet. I would love to hear your thoughts on that. If you like this episode and you want to see past episodes, you can go to lispcast.com/podcast. There you will find all the past episodes including audio, video and text transcripts.

You'll also find links to subscribe to the episodes, either podcast or on YouTube or RSS, if you're doing the blog reader. You'll also find links to social media, where you can get into discussions with me. If you have any ideas on this, email me, tweet me, LinkedIn message me, love to get into discussions and really dig deep into this. Cool.

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