Coding Samurai's Path

OOP vs FP: Fight That Wasn't

Oleksandra Lozoviuk
Content Strategist at Freshcode
Clojure Developer at Freshcode
Volodymyr Pavliuk
Hi, my name is Alex and I am a stickler for FP/OOP/iOS/Darwin's theory of evolution (underline the correct option).

Nearly any discussion of programming paradigms produces a wide variety of holy wars. We just want to break this vicious circle.

So what about benefiting from both functional programming and OOP paradigms? Let's sit down at the negotiating table!


Every programming language is unique in its features and the procedure of code processing and execution. This is called a paradigm. There are several paradigms designed so far but a couple of them were taken up to Olympus: Object-Oriented Programming (OOP) and Functional Programming (FP).

FP and OOP are often seen as something opposite and mutually exclusive while it's reasonable to consider them as companions. FP even is called "the new OOP". But first things first. Let's look back.
Historically, OOP was inspired by ideas of how to make software systems easier to understand and maintain using such cross ideas as 'information hiding', 'modularity', and 'encapsulation'. It shifted programming languages from linear functions/procedures-centered design to object-centered one.
I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.

Alan Key, Computer Scientist, pioneering work on OOP and GUI design

Ivan Sutherland's Sketchpad app (the first program ever to utilize a complete GUI) was an early inspiration for OOP. And the first OOP language Simula is 50+ years old. Its main objects were formulated as follows:

  • to provide a language for a precise and standardized description of a wide class of phenomena belonging to what we may call 'discrete event systems'
  • to create a programming language for an easy generation of simulation programs for discrete event systems

Throughout its development, OOP was facing some issues, such as misusing of code reuse and non-swappable chaotic designs, cases when some things need deciding at runtime instead of compile-time, or pitfalls with concurrency.

It is not the prosecution's arguments or stones in the OOP garden. The issues mentioned above were leading to developments and improvements inside OOP as well as outside of it.

As for the functional programming paradigm, it goes even deeper into the history of computer science discoveries. But in some sense, it was ahead of its time and was shaded by other approaches, more consonant with the computer milieu of those times.
The fact that a single fashion can sweep through the whole industry like OOP did is a bug, not a feature. It's a structural, systematic problem with the field as a whole. <...> Popularity is simply not a good proxy for quality, but people take it as such and all jump on the same bandwagon.

Tikhon Jelvis, Principal AI Scientist


Everything old is new again. How did the story begin?

In the latter part of the 50s John McCarthy, computer scientist, LISP creator, and precursor of the AI boom, realized that the computer milieu of those days (machine code and the new Fortran) didn't fit the needs of the "people in US homes".

He concluded that the networked computers could become a specific ecosystem and there is how the "Information Utility" idea was conceived. Mr. McCarthy was really ahead of his time. Utility computing and time-sharing concepts caused a sensation in the 1960s, but have sunk into oblivion in the mid-1990s. But since 2000, these ideas have been reborn in new forms (service provider, grid computing, cloud computing).
John McCarthy, LISP and AI
John wanted to put ideas old and new on a firmer basis to implement a triad of logic, math, and programming in real-world tasks.

He was developing the idea of the active semi-intelligent agent, the "Advice Taker", that should have been able to interact with users in their commonsense terms, learn from "taking advice", and operate various kinds of logical deductions including those that required actions.

Mr. McCarthy championed lambda calculus, invented garbage collection, and became a godfather of functional programming showing the world the LISP (1958), the first programing language outside the von Neumann model. We have already highlighted it in previous articles: Myths of LISP and LISP vs Clojure.

So, John McCarthy became a pioneer of functional programming over 60 years ago and paved the way for future FP ambassadors to implement it in real-world tasks in the best possible way.

Different programming languages are 'wrapped' around the FP paradigm. From 'canonical' Haskell and LISP to Racket and Clojure. Between them — Scala, JavaScript, and Python, successfully combining functional and object-oriented programming. But more on that later.


Everything depends on our deep understanding of concepts. So, gaps between terms and their interpretation lead to misunderstandings and pointless arguments.

Nearly any discussion of programming concepts will produce a wide variety of holy wars. While they have a lot more in common than people think.

OOP and FP what is better
We've already mentioned that a lot of popular programming languages (JS, C++, Python, etc.) are multi-paradigm. They support different programming approaches in different combinations.

For instance, we can classify JavaScript as both an object-oriented and functional programming language because of the various first-class features it provides. Functions as objects with closures work well in JS. It's even called "a bad OOP language with excellent functions".

Erlang is handling both message passing (OOP) and immutable data & shared state (FP).

While Lisp was "staffed" with specially designed interpreters, Clojure, a member of the Lisp family of languages (FP), runs on the Java platform (OOP). So, it deals with a significant part of the OOP toolkit.

Dynamic and statically typed code, collections-oriented code and individual values, stateful code interacting with users, and stateless pipeline components — all those features are worth discussing, not arguing about. Make code, not war.

The whole mish-mash is neither one thing nor the other, architecturally.

Les Carleton, Program Manager
Quoiting Alan Kay, "OOP and functional computation can be completely compatible and should be!"

Both paradigms have practical benefits and there is no reason to "munge state in objects and invent "monads" in FP". Amen.

Morality: You can be an OOP apologist or believe that FP saves the world — it doesn't matter. Every paradigm is both good and bad — you just need to know how to use it and when to use it; when it fits and where it doesn't.


And although we prefer to focus on similarities and common perspectives, let's briefly compare a couple of the most frequently discussed programming paradigms.
pros of functional programming
1. While OOP describes the world using Objects, which claim to be highly bound to people's minds of understanding, FP uses pure data (sequences, numbers, etc) to describe the world state, and functions over data to describe how the world might change.

2. While OOP implies a strong separation between Data and Behavior, representing those by Fields and Methods respectively, FP considers Behavior as a part of Data, representing Behavior as Functions, which could be manipulated (generated and passed as arguments) like Data.

3. Historically, OOP considers the world to be mutable, so the OOP Data might be mutated by Object methods. This seems fair, as the world is mutable in practice.

On the other hand, FP encourages developers to think about a program as a whole possible reasonable set of changes and states, which allows considering a state as a result of a particular change to another state. This understanding is more mathematical, as in a certain moment of time it's possible to make a State snapshot and make correct assumptions of what exactly led to that.

4. While both OOP and FP work with sequential data (lists, arrays, etc), OOP introduces loops to iterate over these, and in most cases modify each element of a sequence in place. FP uses recursion algorithms to iterate sequences as it needs to have an immutable snapshot of the state after each iteration.

5. Both FP and OOP support parallel programming, but as FP works with immutable states, it does not introduce complex transaction memory models to secure parallel modification while working with immutable structures.


functional programming paradigm
To be honest, we cheated a little and have more space for functional programming in this meeting room. OOP is more widely known and FP stays under some layer of incomprehensibility and abstruseness.

Words matter. Alan Key lamented that he coined the term 'objects' in the context of OOP. Or just remember the 'Curse of Lisp' which was turned into some horror story myth.

The name of the concept of "purely functional programming" also played a trick. Something like it has absolutely no effects. But a general-purpose language without effects obviously would be close to useless.

To quote Mr. McCarthy, "Language is froth on the surface of thought". *sight*

      Purely functional programming is a brilliant idea with a misleading name. When people talk about "purely functional programming", they mean Haskell or something like Haskell. But that's not what the words sound like! This ends up confusing non-Haskellers and leads to tedious arguments about "purity" (whatever that is).

      Tikhon Jelvis, Principal AI Scientist
      You should not "move to" functional programming. But don't let preconceptions or misplaced conservatism stop you from trying it.

      Functional programming languages are beautiful and concise but quite unfamiliar to many developers. Although there are a lot of great things in its arsenal:

          Functions are Values
          Graceful Parallelisation

          No Side-Effects
          ...And Expressions For All
          Guarantees of immutability and referential transparency in functional programming make working with concurrent applications easier. It allows performance to be improved harmlessly. And this is, in our opinion, the most promising prospect.

          Other major features of functional programming are:
              Convenient Higher-Order Functions
              Immutable Data Structures
              Powerful Type System
              Lazy Evaluation
              Recursive Function-Calls
              Mathematical Elegance
              One more great positive point worth noting is the special pleasure of coding through the prism of 'functionalism' mentioned by developers (Clojure, LISP, Scala) in surveys.

              Finally, we want to share with you a brief comparison of the programmatic implementation of OOP and FP approaches, using Sho Miyata's example given in the Medium article.

              You are a sushi bar owner. You love your team. You decided to give all your employees a ¥50,000.00 raise. How to tackle this situation programmatically?
                  functional programming vs OOP code


                  There is no single approach that can work for everyone and everywhere. While delving into computer paradigms, explore as much as possible, and learn the best practices of each paradigm and programming language you use.

                  It's vital for developers to constantly be trying different things and find problem-solving keys among different paradigms and patterns.

                  Let's learn how to do things in the most simple, elegant, and effective way. And nothing else matters.

                      Never abandon a theory that explains something until you have a theory that explains more.

                      John McCarthy, Computer Scientist and LISP Inventor
                      We are always ready to discuss how to build the best systems and provide a better total experience using FP and OOP approaches. Particularly enjoyable for us will be a friendly talk about Clojure perspectives and Clojure ecosystem development.
                      Freshcode welcomes you to talk about it! Please, fill out the form on our website or contact our representative on Linkedin.

                      Arigatō. ❤️

                        What happens after you fill this form?
                        Our representative will contact you within one business day
                        We sign an NDA to keep your ideas confidential
                        You share essential requirements with us
                        Our analysts and developers estimate the budget and timeline
                        Shall we discuss your idea?