Every month there seems to be a new set of tools that the software community is raving about. Whether it’s a new framework, build tool, or obscure language, there always some new fad to learn.
When first introduced to the concept of functional programming, I assumed it would fall somewhere in that “fad” category. A topic I would read a short article about and then move on.
But, with just a few implementations of its concepts many of the issues that had plagued me for years seemed to be less of a concern. When I stuck with functional concepts, I no longer had to deal with monolithic objects that seemed to only grow in size and monstrosity.
With pure functions, unforeseen behavior or spooky side effects, from a distance, were less of a concern. It was as if a light had gone off and I could finally see clearly how much faster and stable I could build programs. If only the tools, community, and frameworks reflected this new paradigm.
Fortunately in the world of programming, especially front end development, we’re witnessing a subtle shift from Imperative to Declarative.
Before we dive into Functional and Object Oriented, it’s important to appreciate the bedrock of modern programming or Imperative and Declarative. For over thirty years we’ve approached programming from an Imperative style. We give a list of commands and tell the computer how we want to accomplish an action. Primarily based on the idea that you are constantly changing something in memory, mutability.
Imperative Thinking
Imperative is built around the idea that while you’re viewing or changing something in memory the rest of the world freezes. One can easily see how in a world filled with concurrency that could be a problem. By now I’m sure you’re wondering why would we ever revert to an Imperative style, but if you look at its predecessor with Procedural it becomes evident.
We’ll save Procedural for another piece, but the real question is – if Object Oriented is so touted why is it imperative?
Perhaps the most concerning idea that Object Oriented promotes is mutating state. It’s so frequent in Object Oriented languages that we simply take it as a necessity of programming. But state makes scaling apps extremely difficult as we have less certainty on values.
[snippet id=”86″]
Take this small example of a few lines of code. Because of mutating state and mutable objects we lose certainty of the value. By the time we console.log the value, it could be anything.
This only grows more concerning as we add other modules and objects. Object Oriented reliance on mutating state is concerning, to say the least.
Take that concept along with inheritance which promotes the idea of unforeseen interdependence – we frequently have code that is filled with uncertainty and hard to reason about.
The excuse that most apologist make for Object Oriented is that its objects serve as abstractions, or interfaces. But its more than just abstractions, OO promotes convoluted code.
The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. — Joe Armstrong
The list goes on on from encapsulation to concurrency issues to polymorphism we could spend a week discussing the problems and only scratch the surface. But I’d rather focus on a “new” way to program. One grounded on the idea that rather telling the computer how to do something, emphasizing what we want.
The important idea to take away is that Imperative is based on a false premise. It assumes that you are the only one trying to interact with a value and that mutating data is a good approach to scaling an app.
The Way Forward
This idea of emphasizing what we want instead of how we want it done is the cornerstone of Declarative Programming.
At it’s best functional programming is declarative programming. It emphasizes small functions that composed together to give the computer what output we want from a certain input value. Think of it as functions mapping values.
[snippet id=”87″]
If you notice in this first example we’re telling the computer how we want to accomplish a task. Whereas in the second example, we emphasize the verbs or action we want to do. But before we dive further into the future lets take a look back.
Looking Back
To truly understand the paradigm shift that functional programming presents we have to think back to just what was capable seven to ten years ago. From a cutting edge company, we could expect a site to look and feel something like this.
We might laugh now, as we should, but the reason it lacks so much is that we simply didn’t have the necessary tools to create our vision.
What we create is directly proportional to the ability of our tools. If in the next ten to twenty years we want to accomplish the goals of virtual reality, machine learning and even things like space travel, the tools we use must become far more efficient and reliable.
We’re already starting to see more functional aspects in OO design with promises, immutable objects and libraries like lodash and underscore. But we’re just at the beginning of a shift and now is the time to become more familiar and comfortable with the topic.
Functional programming is often overlooked because it appears complex, theoretical and dare I say mathematical. Yet in fact its completely approachable. I’ve put together a guide detailing how one can become quickly fluent in functional programming. All you need is a basic understanding of front-end development and JavaScript.
But before you even dive into the guide, I’d suggest to get started thinking functionally by taking a small piece of code and answering two questions about it.
- What is the lifecycle of this object?
- What other variables or objects outside of this object are dependent upon it?
—
This is the first piece in a series The Functional Programmer’s Starter Kit and was written by contributing writer – Garreth Dottin.
