This content originally appeared on Bits and Pieces - Medium and was authored by Ahmad M. Hawwash
Functional Programming Part 0: A Comparison Between Programming Paradigms
This article is a part of a series that talks about “Functional Programming”
In this very first part, we’ll talk about Programming paradigms. Touching Imperative and Declarative paradigms. Running on some minimal examples and comparisons. At the end, we’ll take an evolutionary-perspective look at some paradigms.
Table of contents
- Programming paradigms
- Imperative paradigm
- Declarative paradigm
- Extra mile on sum example
- Evolution perspective
- Conclusion
Programming paradigms
A programming paradigm is a style or a “way” of programming. So some languages force us to write in a certain paradigm. Other languages keep options open up to the programmer. where each paradigm follows a set of concepts. (Please take a look at the heading picture -if you haven’t already, so “paradigm” word can make sense).
In the history of computer programming, engineers have developed different languages. Each language had a paradigm (or more) in mind. These paradigms belong to one of these 2 main categories:
1. Imperative Paradigm
In which control flow is explicit, where the programmer instructs the program how to change its state. Where it includes more paradigms:
- Structural Paradigm
- Object-Oriented Paradigm
2. Declarative Paradigm
In which control flow is implicit, where the programmer instructs the program what should be done without specifying how to it should be done. Where it includes more paradigms:
- Functional Paradigm
- Logical Paradigm
- Mathematical Paradigm
- Reactive Paradigm
Summary
Most languages belong to either Imperative or Declarative paradigm, where each paradigm has a set of concepts to follow.
Let’s talk more about the two main paradigms:
The Imperative and Declarative paradigms.
1. Imperative Paradigm
Imperative paradigm has evolved a bit in terms of structure (because of Structural Paradigm), but it still has problems:
- Telling the program how to do things (control flow is explicit)
- Sharing state
To make the idea a bit closer. Let’s take two analogies for the two problems above (if you understand the problems you can skip the next part and jump to the example):
Problem 1: Telling the program how to do things (control flow is explicit)
- Case: Imagine 1,000 employees with a lead who’s leading them towards a mission. The lead starts telling the 1000 employees how to do things one by one. How bad do you think this is going to be? I am pretty sure you can see that this micro-level management style has major risks, pitfalls and won’t even work.
- Solution: Grouping people in areas of responsibilities and delegate a team leader to each group. The leader of each group should know how to do things for sake of the mission. That’s going to reduce a lot of the complexity, bottleneck and it’s going to be a lot easier to manage.
- In this analogy
— Mission leader = Programmer.
— Groups’ leaders = Higher level functions
— Employees in each group = Lines of code - Conclusion: when we apply higher order organisational structure on the program level, our lives are going to be way smoother.
Problem 2: Sharing state
- Case: Imagine yourself a father, you have 2 children. You created a shared bank account for them. Each month you put $1000 in that account. Both of your children are unaware that the account is shared. So they both think each have $1000 to spend to him/herself. At the end of the month, you are screwed because you found out that you end up with -$1000 in that account.
- Solution: Each child should have separate account and specified monthly amount
- In this analogy:
— Children = Functions
— Shared bank account = shared state. - Conclusion: When your functions share the same state. They use it unconsciously. This will mess up your program state even with only 2 functions. So it’s always better that each function has its own independent state to use.
Example On Imperative Paradigm
Let’s see how sum could be implemented in Imperative Paradigm
Why is this considered Imperative?
- Telling the program how to do things (control flow is explicit): We tell the for loop how to work explicitly. Also we access each element in the array explicitly.
- Sharing state: result variable is a shared state, being mutated on every iteration (sharing state in bigger problems will be much harder to deal with).
2. Declarative Paradigm
Declarative paradigm is when the programmer instructs the program what should be done without specifying how.
In contrast to Imperative paradigm, Declarative paradigm is just not imperative. In other words, in Declarative paradigm we write functions that:
- Describe what a program should perform instead of how (implicit control flow).
- Produce no side effects (which we’ll discuss more later).
Example on Declarative Paradigm
We saw how sum function could be implemented in Imperative Paradigm, let’s see how it could be implemented declaratively
Magical, right? But why is that considered declarative?
- Described what a program should perform instead of how (implicit control flow): There’s no explicit iterator, no explicitly telling the loop how to work or how to access the elements. That was achieved by using reduce.
- Produced no side effects: Shared state is a form of side effects, that was totally eliminated using the composition of reduce and add function.
Extra mile on sum example
What if we wanted to sum only even numbers?
Imperatively we would do:
But Declaratively we would do:
As we see, if we want to compare both paradigms (Imperative and Declarative), in Declarative paradigm (Functional paradigm in our case) is more like gears ⚙️, you develop your gears as separate units, then you add them wherever you need them. But in Imperative paradigm it’s more like dough 🫓 almost everything is mixed and fused into the same piece of code (unless in fact you did great job doing design patterns).
In general, Declarative Paradigm is more:
- Predictable
- Testable
- Reusable
- Customisable
- Cacheable
- Maintainable
- Composable
Some of these points don’t necessarily make sense in context of sum example, but will make sense in future articles.
Evolution perspective
After understanding that we have 2 main paradigms Imperative and Declarative, where each has sub-paradigms. Let’s talk now more about Structural, Object-Oriented and Functional Paradigms. from an evolutionary perspective.
Each paradigm has restricted a way of programming by introducing something new. Where we can say best leaps happened in:
- Structural Paradigm: Restricted usage of goto and “flow of transfer of control” by introducing structure to our code like if/else/then/loop and others. In other words, it constraints the flow of transfer of control.
- Object-Oriented Paradigm: Restricted doing polymorphism using pointers to functions by introducing Polymorphism using inheritance.
- Functional Paradigm: Restricted shared state and side effects by introducing Immutability.
Keep in mind that each paradigm might use one or more of other paradigms’ concepts (for example, both Object-Oriented and Functional paradigms uses Structural Paradigm concepts).
Conclusion
In real life, we have different paradigms with different styles that needs different levels of proficiency. Practicing more paradigms will give you more superpowers, OO has its superpowers and FP as well. The stronger you become in these paradigms, the more powerful your solutions will be, the more safe people will feel around you.
Thanks a lot for taking time reading through this article. I’m cooking the next ones in the series. Please feedback me and let me know what you think in the comments about this article or the coming ones.
This is an article in a series of articles talking about Functional Programming
In this series of articles we cover the main concepts of Functional Programming. At the end of the series, you’ll be able to tackle problems in a more functional approach.
This series will discuss:
0. A Brief Comparison Between Programming Paradigms
- Side effects
- First Class functions
- Pure functions
- Closure
- Currying
- Composition
- Functors
- Monads
Resources
- https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html
- https://cs.lmu.edu/~ray/notes/paradigms/
- https://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html
- https://blog.cleancoder.com/uncle-bob/2017/07/11/PragmaticFunctionalProgramming.html
- https://blog.cleancoder.com/uncle-bob/2012/12/19/Three-Paradigms.html
- https://en.wikipedia.org/wiki/Programming_paradigm
- https://en.wikipedia.org/wiki/Procedural_programming
- https://en.wikipedia.org/wiki/Functional_programming
- https://en.wikipedia.org/wiki/Non-structured_programming
Functional Programming: A Comparison Between Programming Paradigms was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Ahmad M. Hawwash
Ahmad M. Hawwash | Sciencx (2022-01-13T17:39:38+00:00) Functional Programming: A Comparison Between Programming Paradigms. Retrieved from https://www.scien.cx/2022/01/13/functional-programming-a-comparison-between-programming-paradigms/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.