Every developer, team leader and product manager knows that the world moves fast. And I mean fast enough to make us all feel dizzy with weekly new breakthroughs and new frameworks and technologies that rise and die each year. Not only are things changing quickly, the rate at which things are changing, is rapidly increasing. We are living in a time of exponential tech explosion.
The way we built typical applications five years ago is dramatically different from the way we build them today. We’re using tools now that didn’t exist 2 years ago. Go back 10 years and processes were radically different (waterfall vs Agile development). If an engineer wants to survive long-term, and companies want to develop apps as sustainable and strongly as possible, the most important thing we must learn is how to adapt, and how to make our code more adaptable.
The only way we’ll be able to keep up with the exponentially increasing complexity will be to decrease the complexity of understanding programs. We must learn to build more expressive code. We must learn to write programs that are easier to reason about, debug, create, analyze, and understand.
Functional programming is a paradigm shift and can assist us in making this shift.
Firstly, what is functional programming? Well, there is no clear, widely-accepted definition of Functional Programming (FP). It’s a collection of related features which fit well into a useful style of programming and that’s what we’ll discuss in this blog post.
Why Functional Programming?
Before getting our hands in the specifics of the paradigm, it’s a good exercise to think and understand why we may want to choose Functional Programming over other programming styles. Many companies have already seen the benefits of making the shift: Functional Programming is on the rise.
Conceptually, moving away from an Imperative Language (Java, C#, C++, et. al.) will help us gain improvement in the understability of the code, because Functional Programming focuses on the problem itself. That is, Functional Programming focuses on what to do rather than how to do it. Providing a better abstraction for problem solving, lets us stop worrying about iterations, for example. That might sound a small benefit for the effort it takes changing the way we approach code. But when we realize that having a better understanding of the code leads us to a huge improvement in debuggability and maintainability, we can clearly see how that translates into time and money savings that will affect the overall success of the project. Nowadays, multiple startups depend on how fast you can come up with a working solution, how easy is to scale from there, and how those things can be done with as little money as possible. Rework is penalized big time.
What we gain from the Functional Programming paradigm:
- Elegance and simplicity
- Easier decomposition of problems
- Code more closely tied to the problem domain
And through these, we can also achieve:
- Straightforward unit testing
- Easier debugging
- Simple concurrency
Furthermore, the now unstoppable adoption of CPUs with dozens of cores, and therefore the increasing importance of non-sequential programming, will only hasten the rise of Functional Programming, as old models of parallelism bring crippling complexity.
In fact, it wouldn’t be surprising if we see declarative languages (the ones that are needed for functional programming, like Go) and many CPUs to co-evolve. Perhaps what’s holding back the mainstream release of 8+ core CPUs is the inability of most of the software out there to use them effectively, and one thing holding back the rise of functional programming is the lack of many-core CPUs whose exploitation make them all but necessary.
How object-oriented programming differs from functional programming
We can safely say that the limiting factor for developers and companies is how fast they can adapt. Regardless of the exact position within the company you’re working for right now, understanding and embracing Functional Programming will leverage your competencies, especially if we consider that the rate of adoption of Object-Oriented best techniques took us almost a decade.
So, where do we start?
Yes! It’s possible and also it’s fast to learn if you’re already familiar with the language.