Pre-history: What are OOP and FP?
Every programming language is unique in its features and the procedure of code processing and execution. <medium>This is called a paradigm.<medium> 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. <medium>Let's look back.<medium>
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 <medium>object-centered<medium> one.
{{quote-bl48-1="/custom-block-to-blog/one-page"}}
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 <medium>language for a precise and standardized description of a wide class of phenomena<medium> belonging to what we may call 'discrete event systems'
- to create a programming language for an <medium>easy generation of simulation programs for discrete event systems<medium>
Throughout its development, OOP was facing some issues, such as <medium>misusing of code reuse<medium> and non-swappable chaotic designs, cases when some things need <medium>deciding at runtime instead of compile-time,<medium> or pitfalls with <medium>concurrency.<medium>
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 <medium>goes even deeper<medium> 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.
{{quote-bl48-2="/custom-block-to-blog/one-page"}}
Rising Sun of FP: Sensei McCarthy, AI & Clojure
<medium>Everything old is new again.<medium> 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) <medium>didn't fit the needs<medium> of the "people in US homes".
He concluded that the <medium>networked computers could become a specific ecosystem<medium> 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 <medium>triad of logic, math, and programming in real-world tasks.<medium>
He was developing the idea of the <medium>active semi-intelligent agent,<medium> 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 <medium>lambda calculus,<medium> invented <medium>garbage collection,<medium> and became a godfather of functional programming showing the world the <medium>LISP (1958),<medium> 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.
{{ebook-bl48-3="/custom-block-to-blog/one-page"}}
Programming paradigms: Versus or Collab
Everything depends on our deep understanding of concepts. So, <medium>gaps between terms and their interpretation<medium> 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.
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 <medium>JavaScript<medium> as both an object-oriented and functional programming language because of the various first-class features it provides. <medium>Functions as objects with closures<medium> 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 <medium>those features are worth discussing, not arguing about.<medium> Make code, not war.
{{quote-bl48-4="/custom-block-to-blog/one-page"}}
<medium>Quoiting Alan Kay,<medium> "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.
<medium>Morality:<medium> 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 <medium>OOP describes the world using Objects,<medium> which claim to be highly bound to people's minds of understanding, <medium>FP uses pure data (sequences, numbers, etc)<medium> to describe the world state, and <medium>functions<medium> over data to describe how the world might change.
2. While <medium>OOP implies a strong separation between Data and Behavior,<medium> representing those by <medium>Fields and Methods<medium> respectively, <medium>FP considers Behavior as a part of Data,<medium> representing <medium>Behavior as Functions,<medium> which could be manipulated (generated and passed as arguments) like Data.
3. Historically, <medium>OOP considers the world to be mutable,<medium> so the OOP Data might be mutated by Object methods. This seems fair, as the world is mutable in practice.
On the other hand, <medium>FP encourages developers to think about a program as a whole possible reasonable set of changes and states,<medium> 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), <medium>OOP introduces loops<medium> to iterate over these, and in most cases modify each element of a sequence in place. <medium>FP uses recursion algorithms<medium> to iterate sequences as it needs to have an immutable snapshot of the state after each iteration.
5. <medium>Both FP and OOP support parallel programming, but as FP works with immutable states,<medium> 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 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*
{{quote-bl48-5="/custom-block-to-blog/one-page"}}
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:
{{list-bl48-6="/custom-block-to-blog/one-page"}}
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 <medium>promising prospect.<medium>
Other major features of functional programming are:
{{list-bl48-7="/custom-block-to-blog/one-page"}}
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: <medium>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?<medium>
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.
{{quote-bl48-8="/custom-block-to-blog/one-page"}}
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ō. ❤️
{{about-pav-loz-red="/material/static-element"}}
