How does FP achieve reuse?

Functional programming gets its reuse by creating small components that are very well-defined. Small means they're probably generally useful (like lists). Well-defined means they are easy to build on top of.

Transcript

Eric Normand: How does functional programming achieve reuse?

Hi, my name is Eric Normand. These are my thoughts on functional programming. I think that the way functional programming achieves reuse is a different way from how we would traditionally think of reuse. It's that we are aiming for very small components.

I think what happens in a lot of programmers, this happens to me, I'll frame it in the first person.

I really love it when I get to reuse a huge thing for some other purpose. It feels like making something more complex with more conditionals, more IF statements makes it more reusable. This function has so many parameters, I can use it for so many things.

It feels like you're reusing all of this code, but the truth is that it becomes harder to reuse with more parameters, with more configuration, with more methods if it's a class. It becomes harder to reuse because each one is adding complexity and each one is making the thing more fit for more and more specific purpose.

https://twitter.com/ericnormand/status/1067810764319264768

What functional programmers tend to do, this is totally possible in object-oriented programming, by the way. It just doesn't seem to be the trend that people are following. Until FP start...We'll talk about that in a second. What FP people do is, they make tiny little things.

I'm talking about super tiny, like the count cell. It's got two fields and it's got basically two operations, two getters. It just like the first and the rest. It has a constructor and that's it. Now with that, you can create a whole host of data structures, or we'll look at something like this sequence abstraction in Clojure.

https://twitter.com/ericnormand/status/1065334419106553856

That creates a whole...It's very simple. It's like a count cell except it's more of an abstraction. That creates a whole ecosystem of things that abide by this tiny little protocol or the tuple. The tuple is so simple. It's so reusable because it does almost nothing.

What happens in object-oriented programming, and this is...Here's the thing, when I talk about object-oriented programming, in the back of my mind there's a little avatar of Alan Kay. He says, "Wait, that's not what I meant." I'm not talking about what Alan Kay meant. I'm talking about how people practice it today.

What you see is things getting bigger and bigger. Classes have more parameters for configuration. They have more methods instead of getting smaller. You have these things like a giant-person class that your company uses.

This is supposed to be used across all these software at your company but it becomes harder to use, less reusable, less usable by the different parts of your software because it's been customized to each department. The way you make something more reusable is actually by making it simpler. By making it have fewer moving parts.

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

This is why functional programming at the moment is having a big influence because we're actually the ones who are showing, "Look, you don't need this whole like abstract class hierarchy with all these single method classes or interfaces. All you need really is a function, right? A lambda."

Java has added that in. If you look at a lot of the classes that came along with Java 8 were very simple. The interfaces that came with it were just so simple. They were just like, "This is what we need." A function of two arguments, a string and a number. It returns a string. You just have this very granular approach. You start with these little pieces at the bottom and you can build them up.

https://twitter.com/ericnormand/status/1060261020567003146

That's how it works. Here's the thing. This is why it works. It feels really good. [laughs] This is why it doesn't work, why the O-O approach doesn't work. It feels so good to take this thing and reuse it. This giant thing.

It feels awesome when you found a new use for this big thing because you say, "Oh, I just use this whole thing." The thing is, it's more rare, it's harder to do. It feels more like you're a master of the thing and you're getting more effectiveness out of it. Except, it happens more rarely.

Whereas, think of something like the tuple. You use that all the time or a simple HashMap, you can use that all the time. It doesn't even feel special. It's such a small little thing you don't...but then, when you look at how much code you're reusing, it is significant.

The reuse happens. The way it works is, it's logarithmic. It's a tree. You have these little tiny things on the leaves of the tree. You build something a little bit bigger out of these two simple parts and that thing is still pretty simple in itself. That's reusable.

https://twitter.com/ericnormand/status/1073608850526351360

The thing at the top is reusing this huge tree of stuff. Whereas in object-oriented programming, you make one big class and hope to reuse it. It's not made out of those little parts. What's the likelihood that you've got that class right? It's one level. It's like one giant thing as opposed to thousands of little things that get put together.

What's the probability that you're going to be able to reuse that giant thing versus this very simple thing with one use with one purpose? It's very unlikely that you'll get to reuse this big thing. Even if it's like at the top of your tree in a functional programming with this tree of stuff built out of simpler parts and simpler parts and simpler parts.

The top of the tree might be wrong because it's so big. Look how big it is. If it's wrong, you can just go down one level of the tree and all those things are a little bit more likely to be right for their purpose. You go down one level again, those things are even more likely to be right for their purpose.

Even if you get it wrong, you can just go down a level and you're at a better place to find reusable parts.

I've been ranting too much about this. Let me know what you think. I'm @ericnormand on Twitter. You can also email me at eric@lispcast.com.

It's all about the reuse. That's how you gain efficiencies of scale. As your code base gets bigger, you want more stuff to be able to reuse. You don't want to slow down.

Get in touch with me. Follow me on Twitter. Email me. I'll see you later. Bye.