Coding Samurai's Path
APR.20.2022
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!
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!
PRE-HISTORY: WHAT ARE OOP AND FP?
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.
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
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:
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.
- 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
Tikhon Jelvis, Principal AI Scientist
RISING SUN OF FP: SENSEI MCCARTHY, AI & CLOJURE
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).
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 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.
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.
PROGRAMMING PARADIGMS: VERSUS OR COLLAB
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.
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.
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.
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
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.
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.
FP VS OOP: COMPARING PARADIGMS
And although we prefer to focus on similarities and common perspectives, let's briefly compare a couple of the most frequently discussed programming paradigms.
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.
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: BENEFITS AND PERSPECTIVES
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 somehorror 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*
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
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
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:
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:
Other major features of functional programming are:
1
Convenient Higher-Order Functions
2
Immutable Data Structures
3
Powerful Type System
4
Lazy Evaluation
5
Recursive Function-Calls
6
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.
Given: 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?
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.
Given: 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?
CODING SAMURAI PATH: SUMMARY
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.
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
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ō. ❤️
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?
+447383646814
info@freshcodeit.com
info@freshcodeit.com
Services
160 Sobornyi Ave., Zaporizhzhia, 69061, Ukraine
93 Belovodski Put, Sofia, Bulgaria
3 Pan Peninsula Square, London E14 9HQ, UK
93 Belovodski Put, Sofia, Bulgaria
3 Pan Peninsula Square, London E14 9HQ, UK
Copyright © 2023. All Rights Reserved | Privacy Policy
Headquarters