How is Functional Programming like grocery shopping?

Our understanding of the real world has to be applicable to the software world. Our programming paradigms need to correspond to our intuitions of the real world.

Transcript

Eric Normand: "How is functional programming like grocery shopping?" Hello, my name is Eric Normand. These are my thoughts on functional programming.

I've been thinking a lot about this metaphor of grocery shopping. I think it's a good one because it's an imperative thing. It's a thing. It's an action we take in the world. Yet, functional programming has to apply to it because functional programming is a very practical way of programming.

What's going on here? Let me explain why I think this is a good example to look at.

If you were to list the steps of what it takes to go shopping for groceries, you might say something like, "I'll get in the car, I'll drive to the store, and then I'll go down the aisles of the store, and I'll put things I want in my basket. I'll go to the checkout and I'll pay for them. I'll load them in the car. I drive home, and then I put them in the refrigerator."

That seems pretty reasonable, but if you look closely, a lot of it is left out. In fact, maybe one of the most important things is left out. I'm not talking about all the little sub-steps like how driving to the store requires you to take the key out of your pocket, and put it in the engine and turn it. I'm not talking about that.

I just assumed that those are understood. What I am talking about is something that is just really missing.

If you look at the steps I said, walk through the store, walk through the aisles and put the stuff you want into your shopping cart. Click. I left out. How do you figure out what stuff you want? I didn't say how we did that.

I really think that that's one of the keys to why functional programming is successful. It's it forces you to think of that as an explicit step.

Here's what I mean. If you look at the three domains — actions, calculations, and data — and analyze this problem that way, the actions are the stuff I listed before. It's go to the store, put stuff in your shopping cart, stuff like that.

The calculations are like your thinking, your decision making, your planning. You could actually plan your shopping trip. You can plan on what you're going to buy. It's something that we often leave out.

Functional programming brings it and gives its full place. I don't know about you, but when I first started grocery shopping for myself, I would go to the store without even thinking about what I would need. I would get to a section, and be like, "Do I have milk?" I didn't plan. I didn't think about what I had and what I needed.

The trip would often...I would buy stuff I didn't need. I'd forget the stuff that I did need. It was very inefficient.

Functional programming gives a place for that kind of thing. That's what it is. The calculations, the planning, the decision making, maybe simulating a hypothetical situation like, "What would I choose if I had half a gallon of milk? Would I buy another gallon if I knew I wasn't going to go back to the store for three weeks?" Things like that.

https://twitter.com/ericnormand/status/1029080384116539392?ref_src=twsrc%5Etfw

Those are all just done in your head. They have no effect on the real world. They're a perfect place for calculations.

That's what I've been thinking about, that calculations are these nice things. They let you think about what you would do without taking any action, without having an effect on the world. You could plan out your trip to the store. You could plan your route through the supermarket. Of course, it gives you a way to think about the data. Your shopping list could be your data.

Of course, there's all the actions you take while you're shopping. It's the driving, the paying, putting stuff in your shopping cart, loading stuff in your car, that kind of thing. Those things are actions.

Let me know what you think about this. This has been rambling. Still, I think it's useful. I'm going to keep going because this is a pet peeve. I feel a rant coming on.

One of the things that I would like to champion is that functional programming is actually more intuitive than imperative programming. By intuitive, I simply mean it gives places for things. It gives names for things that we deal with in the real world more so than it gives places for things that we deal with in the computer world.

Those examples I've given a lot is that in the real world, we want our records to be permanent. We do a lot to archive papers, keep them in filing cabinets, put them in fire-proof boxes, stuff like that. We try to make sure that they'll last forever.

https://twitter.com/ericnormand/status/1055897462190292998?ref_src=twsrc%5Etfw

We enforce disciplines like you can't change it once you've written it. You date it. You put it in the cabinet. All you can do now is read it.

People talk about programming languages like imperative programming being intuitive because you're taking steps, right? Except then if you can mutate stuff, you're taking steps but the steps you're given is like pull this bit of memory into this variable and then modify it again, and then put it over here.

It's not really intuitive in the sense that you've learned this since child's birth, since you were born. You now understand this thing really well because it's something you've dealt with so many times.

You have object-oriented programming. They talk about it being intuitive, that the classes are the nouns and the methods are the verbs.

First of all, that's not that intuitive. A lot of people have trouble with that. In school, even in high school — and I went to a very good high school — there were students who couldn't underline all the verbs in a sentence. This is in high school.

To say, first, that that's intuitive is just wrong. It's not as intuitive as the associative property of addition, for instance. That's something you can learn about the real world by playing with rocks.

I also don't think that it's true. [laughs] It's not intuitive, and it's not true. If you were to take a description of a problem and turn all the nouns into classes and all the verbs into methods, you would not have a very well-written system. It just would not do the job well. Even if it worked, it wouldn't be in an intuitive way.

The example I like to give is if you were talking about this grocery shopping experience, you might have broccoli, which is a noun. You give it a verb, buy. What you're doing is sending a buy message to a broccoli. It's just not what we do when we go shopping. It has nothing to do with the actual physical shopping experience.

I know that that's not how real inventory management systems are written. That's fine, but that is the rhetoric that people use to justify that their language, their OO language is more intuitive. I think it's wrong. It's not true. It's not the way that you would write that system.

Even if you did write it that way, that's not intuitive in either the sense of knowing nouns and verbs is easy. It's not intuitive in the sense of that's actually how the real world works. It doesn't match our experience. It's something totally foreign, to send a buy message to a broccoli. We just don't do that.

Now, I'm not going to sit here and break down what we do do when we shop. I'll leave that to you as an exercise. That's actually fun because I think that the object-oriented approach would work well if you did the right analysis. This is not the noun-verb analysis.

There is another argument that object-oriented programming is more intuitive. It has to do with objects, like the world is made of objects that behave in the world. Now, I think that this is true. The world has objects in it, and they behave in the world. You could think of the objects and what their behavior is defined by the class and all the methods in that class.

That is true, but most languages we have do not actually let you define real behavior. Let me put it that way. If you go to small talk where you had objects drawn on a screen, you could simulate, let's say, an ant colony by making each ant an object.

It would have some kind of clock ticking so that every tick of the clock, it would call this method. That method would move it forward. It would do whatever an ant is supposed to do. You would press run, and it would pull all the ants and start walking around. They would look like a real colony of ants.

That's very intuitive. The ant is there on the screen. You increase its X and its Y. It moves. It just works really well. That doesn't help you when you're actually buying a broccoli. It might help you simulate a shopping experience, simulate what it looks like to observe the whole grocery store where you have an object that's the buyer.

They walk around the store. They put stuff in their cart, little pictures of stuff, but [laughs] it doesn't help us keep track of how much money you owe. It doesn't work. It doesn't fit. To keep talking about it like it fits is wrong.

The stuff that fits...If you were to actually finish implementing that simulation of a grocery store, you would have to simulate the backend of the store — the inventory management, the purchasing, the printing of the receipts, and the money collection, all that back end stuff, that could then become your backend of a real store.

It's not going to be the same kind of person class with a buy method. It's not. I have a whole talk on this. I call them lies in the talk just to have controversial name, an aggressive name to get more views on it.

The talk is called "Lies My OO Teacher Told Me." It's nothing against OO. It's the rhetoric and the way it is taught. It's a bunch of lies. It's a bunch of falsehoods that you should put a buy method on a broccoli. Why are you even representing the broccoli as an object in the first place? I don't think it makes sense.

That's why I've been thinking about groceries, because I think that to explain FP, I need to take some problem that definitely has its imperative counterpart. It's just a bunch of effects you have on the world.

There's this other part like, "Why would you separate out the thinking, the planning, the thought process, the decisions? Why would you do that?"

That lets you think about hypotheticals. Isn't this much more intuitive to think that there's a place for planning?

Anyway, thanks so much for listening. I really appreciate that you're there. I really love it when I get messages from people, either agreeing or disagreeing. I get both. I don't get many neutral messages, I guess that's normal.

Please, my Twitter is @ericnormand. I would love to hear from you. Just send me a message, and we'll get talking. I love conversations. All right, see you. Bye.