What is functional programming, and how is it different to OOP?

203 viewsEngineeringOther

I’m a mid level Swift developer and I’ve only ever worked with the Object Orientated Programming paradigm.

I’ve heard about functional programming and I tried Googling what it is, but I couldn’t understand the resources that explained it. Also, reading functional code is even more confusing.

So I was hoping that someone who understood it could break it down in incredibly basic and simple terms, and the benefits/drawbacks that it has compared to OOP.

In: Engineering

8 Answers

Anonymous 0 Comments

Im not sure where to start for you.

But lets start with pure functions. These are functions that have two basic properties. They always give the same output for the same input, this is in contrast to OOP where the output depends on the object even with the same input. Second property they dont modify any variables or arguements or anything else ie. they dont have side effects. This is also basic property of functional programming as a whole once you intialize a variable you cant change the variable. If you want to use another value you have to create a new variable. Another thing is you dont have while or for loops you do loops by recursion. This also what makes it probably hard to read for you.

And for the benefits/drawbacks copied from [https://www.geeksforgeeks.org/functional-programming-paradigm/](https://www.geeksforgeeks.org/functional-programming-paradigm/) :


1. Pure functions are easier to understand because they don’t change any states and depend only on the input given to them. Whatever output they produce is the return value they give. Their function signature gives all the information about them i.e. their return type and their arguments.
2. The ability of functional programming languages to treat functions as values and pass them to functions as parameters make the code more readable and easily understandable.
3. Testing and debugging is easier. Since pure functions take only arguments and produce output, they don’t produce any changes don’t take input or produce some hidden output. They use immutable values, so it becomes easier to check some problems in programs written uses pure functions.
4. It is used to implement concurrency/parallelism because pure functions don’t change variables or any other data outside of it.
5. It adopts lazy evaluation which avoids repeated evaluation because the value is evaluated and stored only when it is needed.


1. Sometimes writing pure functions can reduce the readability of code.
2. Writing programs in recursive style instead of using loops can be bit intimidating.
3. Writing pure functions are easy but combining them with the rest of the application and I/O operations is a difficult task.
4. Immutable values and recursion can lead to decrease in performance.

Anonymous 0 Comments

Functional programming deals with functions, that is programming snippets that are basically “given this, do that and return the results”

I think I should use an example: you have a program that draws a bouncing ball.

In OOP, you would have a Ball object, and the program would then operate on it – change its properties like position, ask it to draw itself and such.

In functional programming, you would have a bunch of functions, probably running in a loop, like drawBall, or moveBall, and some variables to track its position. If those are pure functions, they wouldn’t even affect the state directly – for example, your moveBall function would return new coordinates of the ball and then your program would set the state to the new position.

If you then would want another ball, you would add more variables (maybe an array), adjust the functions to take an index of the ball to move or draw, and if one day you would like to have other things like cubes moving around, you would have to accommodate all that.

With OOP, you would just add more Ball objects, and you could also create new Cube objects, and then have them both inherit from a more general object.

At that point your moving and drawing code wouldn’t need to know anything about the balls and the cubes except that they all have positions and can be drawn.

Anonymous 0 Comments

Functional programming is a form of declarative programming, which is usually contrasted with imperative programming. In imperative programming, you give the computer a list of instructions, which it carries out in sequence (OOP is a special case of imperative programming). In declarative programming, you give the computer a series of definitions and then ask it for something – it will work out how to combine the definitions to achieve the required result. Those definitions can be combined to create more complicated definitions, but they generally can’t be changed – you can’t say “x=2” and then “x=3” a few lines later, because “x=2” was the definition of x, rather than an instruction to store a “2” somewhere.

Functional programming emphasizes the role of functions: most of a program will consist of function definitions. Functions can take other functions as arguments, and recursion (calling a function from inside itself) is allowed, but typically only a special type called tail-call recursion, which is easy for the compiler/interpreter to reason about and optimize. Loops generally don’t exist, so recursion is used frequently.

In practice, functional programming languages often allow for some imperative stuff, just as imperative programming languages often have some functional stuff (e.g. many of them allow you to pass functions as arguments to other functions).

The advantages and disadvantages are pretty debatable, like with many other programming styles. For most people, the deciding factor is how popular a programming language is within their specific application area.

Anonymous 0 Comments

I’m not sure how well I can do an ELI5 but maybe more like an ELI16. If you’re familiar with the idea of a math function, a functional program is built up through functions. Now, I’m not talking about the term function as we use it in procedural programming. I mean pure math functions.

Also I would say it’s more pertinent to compare and contrast FP to imperative and procedural programming in general than OOP in particular.

A simple example would be something like:

multiply(2, subtract(10, add(2, 3)))

This creates a function chain where add(2,3) = 5 gets evaluated. Then subtract(10, 5) = 5. Then multiply(2, 5) = 10.

Now you might be asking, don’t all programs have functions? At least, the term function gets thrown around a lot in other programming languages right?

Well, the thing is, the functions in a programming language like C are *side effecting*. What that means is that you can access variables and memory outside of the function through things like global variables or passing pointers or manipulating variables from a visible scope. What this means is that if you invoke the same procedure with the same inputs, the behaviour of that function might change based on the external conditions/state of the program.

The term “function” is also a bit overloaded because “functions” in languages like C and JavaScript or C++ or Java tends to be a catch all term for subroutines, methods, procedures, etc. that may not have any outputs at all (when you return nothing at all or return void).

In functional programming, a function must behave like a pure math function. It must have inputs. It must have a single output. Period. No scope. No side effecting behaviours. You can only manipulate the inputs.

So with pure functions, you strictly work with inputs, and you must get an output, and then pass that output to another function. You can think of it like a factory. The whole program consists of inputs that go onto a conveyer belt, get transformed into something else, then move onto the next step (function) of the process, and it keeps going like that you get the final output. One important thing is also that the same inputs will always give the same output, which is different from side effecting functions.

This is different from imperative/procedural programming, because imperative/procedural programming works more like a list of steps that branch out depending on conditions or overall state of the program. The steps can take any inputs and give any outputs in any order as long as you have the memory to store it. The inputs and outputs can change depending on the state of the whole program. There aren’t things like if statements or loops in FP, and so therefore no hierarchical scope.

Now, that’s not strictly true as there are explicit ways to have side effects and scope, but those are advanced topics in functional programming. In FP, conditionals exist but they’re are treated more like piecewise functions in mathematics. Loops are handled by recursion. Scope is handled through a concept called closures. Side effecting behaviour is handled by a tricky concept called Monads. Again, it gets very confusing and that stuff goes so far beyond a ELI5 level I couldn’t even begin to explain it, each concept would require its own ELI5 individually.

Anonymous 0 Comments

A function in mathematics is something that takes an input and will produce a result based on that. Something like f(x, y) => x + y

Any input will always produce the same result. Most programming languages implement functions.

If you provide the input 2+3 it will always return 5.

This also has a procedural element. A list of sequential operations. Typically languages can also affect other global state. Functional programming doesn’t do this. Nor does it do loops – at least not in the way procedural languages do.

Data can be quite complex, including structures and lists.

You can do functional programming in most languages but they don’t enforce it. You’d normally use a dedicated functional language though since they have helpful features.

OOP is about everything being encapsulated in objects. The objects incorporate operations and can be modified directly.

Anonymous 0 Comments

I’ve been programming since the eighties, so when I started we only had functional and procedural programming – OOP didn’t become much of a thing until the late eighties, and really took off in the nineties.

As others have said, functional programming is centered around functions – functions take arguments as input, carry out calculations/logic based on the arguments, and return an output. In really strict functional programming languages there are no persistent side effects – the function doesn’t alter any of the inputs, and doesn’t change the global state of the program. All it does is return a value or values up the chain to the calling function.

Functional programming is excellent for solving problems that translate well to mathematical concepts – matrix algebra (3d graphics, bitcoin mining), graph theory problems (vehicle navigation), statistical modeling, etc.

OOP came to be because there are a lot of problems that are more intuitive to think of in terms of objects with sets of behaviors. If you have a horse in your game and you want your horse to eat some grass, it’s more intuitive to say horse.eat(grass) rather than setting up a bunch of functions to calculate the various things that should change in your program when the horse eats. It’s also self-documenting, assuming you use reasonable naming conventions, and easier for a programmer who comes later to read.

In a modern program you’ll likely see a mix of functional and object-oriented programming. For example, Swift on Mac/iOS is OOP but you’re still likely calling some lower level C functions for some graphics calculations or other legacy stuff.

Anonymous 0 Comments

At it’s core it’s functions as values, a variable can represent a function. Concept of “pure functions” just makes functional programming “work” (though I guess this has a math context also :), otherwise it would be a mess. You can distill pure functions into functions that cannot fail unexpectedly or have any kind of mutating state. In functional programming immutability is favoured by default.


* Data manipulation with immutable datastructures and functional style apis is incredibly nice.
* No mutating state / pure functions makes the code easier to read, no surprises
* Compile time safety can be maximized. It’s not simple to define what this means but javascript is an example of the other end of the spectrum, Java is in the middle and some functional languages at the opposite end of js.
* I like errors as values vs thrown errors (in general throwing errors is avoided)
* Passing functions around gives a lot of power
* My worst functional code is better than my worst imperative, it’s harder to write truly bad code. The same applies also for my best.
* Monads


* Trail/error learning in general is not as effective as in imperative languages. Example: if you know a little python you can slug it out on some problem, with functional programming you can get simply stuck.
* Being a type astronaut, you can create most amazingly complex abstractions for simple things
* Performance is sometimes worse vs imperative
* Monads

Anonymous 0 Comments

Since you are a programmer, the best way to understand the difference is to explore and try some stuff in a purely functional language like Haskell. You’ll (maybe unpleasantly) notice the differences real quick.