Why Functional Programming?
“Grokking Simplicity is by far the gentlest introduction to FP I've encountered and I've been recommending it to people that want an on-ramp to FP ever since.”
Functional programming is an exciting paradigm which will help you write better code. But will it benefit you, the programmer? In this article, we explore 11 benefits to you for learning functional programming.
Table of Contents
- Functional Programming is Fun
- Functional Programming is Growing
- Two Ways are Better than One
- Functional Programming Makes You Look Smart
- You Will Learn Monads
- Functional Code is Shorter
- Functional Code is Simple
- Functional Programming will Improve All of Your Programming
- Functional Programming has a Long and Storied History
- Functional Programming Makes Concurrency Easier
- Functional Programming Embodies Good Software Practices
1. Functional Programming is Fun
I was this close to quitting software engineering. I was tired of jobs writing PHP or Java or JavaScript. I wanted a challenge and something interesting. What drew me back as I was about to leave? Functional Programming.
2. Functional Programming is Growing
I started doing functional programming back in 2001. Back then, if you talked to people online, even those who had been programming for a while, there was no hope for getting a job in Lisp. It was like an urban legend. People knew people who told stories about people who had jobs. But mostly they remembered how easy functional life was in the 1980s.
But it's different now. People are getting paid to work in Clojure, Haskell, Elixir, Erlang, Scala, and more. They're talking about them at conferences. They're blogging and tweeting FP. FP is a viable career path.
Check out this graph of survey results:
Scala, Swift, Clojure, Haskell, Erlang, Elixir, and F# are all in the top 15.
Source: O'Reilly 2016 European Software Development Salary Survey
3. Two Ways are Better than One
Some people are going to tell you that Functional Programming is better than the other paradigms. Some people will say Object Oriented is better. They might be right. They might be wrong. But what is clear is that a person knowing Object Oriented and Functional is better off than someone only knowing Object Oriented. It's like having a hammer and a saw. Two different tools let you do more.
4. Functional Programming Makes You Look Smart
When I moved back to New Orleans in 2012, I told someone that I was working in Haskell. He literally dropped down to his knees and said "We're not worthy!"
It was half joking and totally unjustified. But only half joking.
You don't have to be a genius to learn functional programming, though that is the stereotype. It's unfortunate. Functional programming is very accessible. But, of course, you can keep that a secret if you want to impress people ;)
Joking aside, knowing how to program in a different paradigm will help you fill niches others can't. You'll solve problems that were made for FP and it will look like magic.
5. You Will Learn Monads
Monads are not that big of a deal. But learning them is a challenge. There is a law of the universe that says that once you "get" monads, you have an incredible desire to share them with the world but lose all ability to communicate how they work.
The best way to learn monads is to approach them gradually. You can use Haskell very productively without learning monads. Eventually, just by exposure, you'll get them. That's what happened to me.
6. Functional Code is Shorter
You may have heard it before, but I'll say it again: Functional code tends to be shorter than equivalent code in non-functional languages. See this paper about a project at Erlang and their estimates of how much shorter it is than an equivalent C++ program. Spoiler: C++ is between 4 and 10 times longer than Erlang. Here is a quote:
Some concrete comparisons of source code volume have been made, as applications written in C++ have been rewritten in Erlang, resulting in a ten-fold reduction in the number of lines of uncommented source code. Other comparisons have indicated a fourfold reduction. A reasonable conclusion is that productivity increases by the same factor, given the same line/hour programmer productivity.
When measuring product quality in number of reported errors per 1000 lines of source code, the same relationship seems to exist: similar error density, but given the difference in code volume, roughly 4-10 times fewer errors in Erlang-based products.
7. Functional Code is Simple
In the Clojure world, the concept of "simplicity" has an objective meaning. We have taken to agree with the research done by Rich Hickey and his powers of presentation. In Simple Made Easy, Rich Hickey presents a definition of simplicity that deals with how intertwined things are. It's not about "ease".
That definition is what I mean. But the concept applies to the broader functional programming world as well.
8. Functional Programming will Improve All of Your Programming
Programmers who understand more than one par adigm are better programmers. They have more tools in their toolbox. So even if you're writing Object Oriented code at work, knowing functional programming concepts will help you with that code. In the end, the principles of good code are the same. OO and FP simply approach the same problem from different angles. Seeing in multiple angles will let you solve your problem in a better way.
9. Functional Programming has a Long and Storied History
Lisp was invented in 1958 and has been copied and reimplemented countless times since then. Each time, important lessons were learned. Those lessons are felt when you're coding with it. Functional programming is one of the first paradigms (invented around the time of procedural) and has fed the other paradigms ideas and features since its inception, including the if statement. You will learn a lot just by working in a language with so much history.
10. Functional Programming Makes Concurrency Easier
Immutability and pure functions were made to work on multiple CPUs.
11. Functional Programming Embodies Good Software Practices
In college, my professors gave me lots of advice about best practices in software. But the code for the languages we used didn't follow those practices. It was hard to accept their advice. I would have to implement the advice by discipline and hard work---with no help from the language. Then when I got into functional programming, I realized that functional programming did all of those good practices by default.