Last week, I found myself caught in the firing range of functional programmers — all because I dared put forward an alternative mode of thinking for JavaScript. This is probably also the first time I’ve ever gotten hate and love mail, public condemnation, accolades and tweets for something that had innocent intentions and origins. Somehow, I also managed to get myself labeled a purist, among other things.

But I am hardly a purist. Rather, I often describe myself as a hybrid and adaptable solutionist — simply because the real world, its requirements for solutions and constantly changing needs is ever clean cut.

What’s the big deal with functional programming?

Functional programming is a programming paradigm that works under idea and assumption that what you put into the function is not expected to change. It stems from the mathematical idea where an equation returns an expected and only that value equivalent of y when x is plugged into it.

A function is an equation for which any x that can be plugged into the equation will yield exactly one y out of the equation. — “Working Definition” of Function

From a maintenance, logical and structural standpoint, functional programming excels when there are no histories to deal with. It works particularly well when there are no boundaries required, or those boundaries are already predefined. It thrives in situations where the state is not a factor and there is very little to no involvement with mutable data.

Recently, functional programming had a surge in popularity through React. The library works well under the functional programming paradigm because it provides an environment where you’re not required to manually track states. Boundaries are also pre-created for you through the idea of components.

This is in opposition to Angular 2+, where classes are required due to the expectation that applications built will cross several logical boundaries. React, however, has a predefined scope with a completely different method for thinking about separation of concern, which further bolsters the use of functional programming paradigm.

Functional programming is much loved by its advocates because it’s easier to emulate real-world processes than objects. It’s mathematical roots lend well to situations that require calculations or anything that requires processing and transformation. Using OOP in these situations may be a bit overkill, if not inefficient.

What’s the big deal with object-oriented thinking?

Once upon a time, object-oriented programming paradigms used to be a marginalized way of thinking back when it first came out in the early 1970s. It gained popularity through Java and C++, which have morphed and shaped the idea of OOP into what we know today.

The main big deal with OOP is the ability to encapsulate data from outsiders.Encapsulation is the ability to hide variables within the class from outside access — which makes it great for security reasons, along with leaky, unwanted or accidental usage.

When you’re working across different boundaries, OOP an excellent method to keep everything packaged up and secure from unwanted external usage. As a result, back end languages advocate and enforce such a paradigm on developers. It helps manage ideas into silos and in a way, OOP is like a ring fence around methods and modules — which are actually just functions but with added benefits.

Object-oriented programmers love OOP because it forces modularity by sectioning off the code into a mentally digestible size and offers up the ability to handle states. Methods become access points to the state and process the instance of the object as required.

There’s a time and a place for everything

Functional programming and Object-Oriented programming are both valid paradigms and methods of coding. However, one will thrive and work better for the project based on environment and requirements — but neither solution works best in all situations.

Functional programming works well when complexity is contained. It thrives in front end spaces because back ends are often giving objects for front ends to process. The client doesn’t care about maintaining object states. It’s already given to them, probably in the form of a JSON object. You don’t really need to play inception by putting an object into an object.

Object-oriented thinking works well in the back end because most of the time, you’re required to construct something to give to the next boundary. It needs to be packaged up, wrapped in ribbon before posting it away into the unknown.

Final Words

Falling in love with code means falling in love with problem solving and being a part of a forever ongoing conversation.— Kathryn Barrett

Both paradigms have their own issues that developers face. Functional programming has spaghetti code through too many dependency injections and OOP has lasagna code through too many layers.

But the question you should be asking is not which is better than the other — but rather — which thinking paradigm will solve your particular problem most efficiently. The size and type of problem are defined by you, the developer, and not through functional or object-oriented methods. Programming paradigms exists to solve your problems and not the other way around.

It doesn’t matter what language you use or what paradigms you enforce, all systems eventually fall apart when it collapses under its own complexity. Complexity itself also cannot be avoided — especially when there are more than one brain involved. Business requirements change, marketing comes up with some wacky requirement that destroys your original architectural plans or the boss wants something completely different — something will catalyst your creation into complexity and there’s no stopping it.

You can only slow it down — not by enforcing only a singular paradigm onto everything — but a hybrid solution that best solves the issues faced.