Why is functional programming gaining traction? Why now?

The biggest companies in the world are investing heavily in functional programming. From Facebook building React and Reason, to Apple pivoting to Swift, to Google developing MapReduce, functional programming is gaining traction. But why? I go over four hypotheses and evaluate them.

Transcript

Eric Normand: Why are the biggest companies in the world investing in functional programming? Why now? What's going on? Hi, my name is Eric Normand, and these are my thoughts on functional programming.

Big companies are using Functional Programming

Across the board, we see companies investing in functional programming. Talking about Facebook, they're doing a lot of stuff, most notably with ML. They've got this thing called the Reason, which is a language with an ML backend, but it's got a JavaScript frontend syntax. They've also done React, which they keep talking about as a functional paradigm.

They're doing stuff with Flow, so typed JavaScript. Functional programming all over the place. They did Haskell internally. It's just everywhere. Apple, the biggest company in the world, has moved its main language from Objective-C, which is an object-oriented language, to Swift, which is much more inspired by Haskell and other functional languages.

JavaScript is becoming more and more functional every day. Scala, Clojure, Elixir, Erlang — these languages are just becoming more and more popular. The question is, "Why now? Why so much investment? What's going on?"

Hypothesis #1: The number of programmers is growing

Hypothesis one is that there have always been functional programmers. Functional programming is an old paradigm. It hasn't just emerged out of nowhere. It was there very early on. Object-oriented is the newcomer, but why now? It could be that just due to sheer numbers.

The number of programmers who are inherently inclined to functional programming is growing, just the absolute number, because the number of developers in general is growing. It's growing exponentially. At some point, you're going to hit a critical mass where you're going to start to hear about it.

There's a big enough community to have their own conferences, to have their own blogs. They're going to have some effect on the broader world. Maybe that's what we're seeing. I think that there's something to that.

One of the reasons why functional programming is taking off is that functional programmers are numerous enough that they can organize. They can have their own trade publications and stuff like that. There's something a little bit to that.

Hypothesis #2: We have to program our many cores

Hypothesis number two, which is the argument I hear the most, is that we're living in a multi-core world. We can't speed up our processors anymore. The only way to get that speed up is to run in parallel. You have multiple threads, whereas before, you could just wait 18 months and your single-threaded application would get faster.

I don't buy this argument. The problem is that we aren't seeing the number of cores increasing on our CPUs. The transistors that Moore's law would predict are moving toward into the GPUs. Functional programming, the general purpose functional languages, they don't really have an answer to GPUs, not a great answer.

Functional paradigms should work on them, but it will take a lot more time before we can use them from a general purpose language in a way that would feel very comfortable and native, so I don't buy that argument. It was a valid argument when we were predicting that everyone would have 1,000 cores on their machine very soon because it was happening.

It was like, "Oh, I have one core. Now, two cores. Now, four cores. Now, eight cores." In the 10 years since that argument came out, we now have 16 cores. It hasn't increased exponentially like we thought, so no, I don't believe that.

Hypothesis #3: We are drowning in complexity

Hypothesis number three is that we are drowning in complexity. These tech companies are just full of software, full of code. They just need something else to organize around besides the standard class-based, object-oriented programming that they were started with, or maybe even the imperative programming they were started with.

There's a lot to that. These companies are spending more and more per line of code. They're spending more and more per feature. They're realizing that, if they invest in better abstractions, better technology, that they will, in the long run, gain a lot of advantage. Their lines of code will be cheaper and their features will be cheaper.

The question is, why not object-oriented programming?

Isn't that full of great examples of design? The answer is that, although...Objective-oriented programmers invented this idea of software design of how to modify your code so that it's easy to modify so that you can add new features.

Even though they did pioneer that, it's fallen short. It actually is a lot of work to develop your software in that way. Is it working? That's the real question. Is it enough to just move your methods around and come up with smaller methods and things like that?

A short rant on the Design Patterns movement

I'm just going to say this. The patterns movement for how to design these reusable things, reusable patterns — not reusable code, but the patterns are reusable — it just didn't have the effect that it was supposed to have. The effect it was supposed to have was to teach people these design principles.

Just looking at what actually happened, I think it's made code worse. I'm just speaking in general from what I see of enterprise code bases. You just have a lot of abstract factory proxies and not a lot of stuff happening. It's unfortunate because there's a lot to the design pattern movement that just doesn't come across.

Maybe it's too hard. Maybe it's touching at something that's so abstract people can't handle it. Whatever happened, in the actual real world it didn't work. Where do you turn to? Functional programmers. Functional programmers model in a different way. They tend toward simpler models. More elegant mathematically-oriented models.

I'm not saying you can't do that in object-oriented programming. I'm just saying people aren't doing it. People like to write factory method. They like to write singleton classes. These are abstractions that take more code than they save, let's say, whereas functional programmers are the ones thinking deeply about how to make things simpler.

Sorry, it's just the truth. It's the truth that I believe. It's my truth. When I look around at the world, what's actually happening is functional programmers who can see the lines of simplicity and how to design things more elegantly. Not everybody. Not everybody, but as a whole, generalizing as functional programmers.

When Apple needs a new language that's going to define the next 30 years of their code, they turn to functional programming. That's what they did. They said, "Look, object-oriented programming? It's not helping. We can't patch this language anymore and maybe we need a completely different model." That's hypothesis number three. There's a lot of merit in that.

Hypothesis #4: All software is a distributed system

Hypothesis number four is that it's not the number of cores. It's not parallelism in that sense. It's the distributed systems. All the software we write nowadays is a distributed system. Whether it's on the web or on mobile, we are writing distributed systems. That's our jobs now.

Not that object-oriented people, object-oriented programmers, object oriented- design can't handle that. It's that functional programmers have been thinking about distributed systems and have the right questions to ask that object-oriented design has not asked, has not gone into very much.

Functional programmers talk about time. They talk about synchronization. They have models of CRDTs. They talk about associativity, commutativity. These properties are very useful in a distributed world.

Just real quick, you have distributed systems when you have multiple computers talking to each other. That happens in every Web app because you have at least a browser and a server, but you have more than that in most cases. You have the database servers, you have the APIs you're accessing. That could be all the AWSAPIs. Those are other computers you're talking to.

You have your Web server. You have thousands of connected clients at the same time. Your mobile app is not a standalone app. It's talking to a server. Has to synchronize with iCloud or whatever it's talking to. These things change the game. It's not a step-by-step do-one-thing-at-a-time paradigm anymore.

It becomes, "I just got this message from outer space from some other computer somewhere, and now I have to deal with it, and I have to make sense of it, and apply it to the state that I've got on my machine in this local process. What does that look like?

"Now the user has done this and I got to send a message somewhere else and try to reconcile all these messages from all these different places." Functional programmers have been thinking about that, that's all. We've been doing that. Our languages reflect that. Our ideas, our thinking, our way of speaking.

Conclusions

Those are four hypotheses. Yes, the number of developers is growing. It's going to make the number of functional programmers grow. That's natural. These two other problems of having better models that help you simplify the complexity that these big companies are dealing with, especially with large amounts of data.

That one and also the fact that we're all working on distributed systems nowadays means that we need to be asking questions that don't come up very often when you look at object-oriented design. They come up in functional designs. That's why we're seeing companies investing more and more in functional programming.

All right. My name is Eric Normand. This has been a thought on functional programming. Please, I'm on LinkedIn. You can get in touch with me. You can connect with me. I'm Eric Normand. Just search. Eric Normand Clojure you'll find me. I'm @ericnormand on Twitter.

Please, if you got an angry Tweet, let me know. Follow me. All those things. Also you can email me if you have something longer to say. All right, see you later. Bye.