DEV Community


Discussion on: Functional Programming vs OOPS : Explain Like I'm Five

bhaibel profile image
Betsy Haibel

Ooof! I can't blame you for being confused here. The definitions of "functional programming," "object-oriented-programming," "logic programming," or any other programming paradigm out there aren't set in stone. In a practical sense, they shouldn't be. It matters more how any given language uses functional ideas, or object-oriented ideas.

(This is even more true nowadays than it was forty years ago. Forty years ago, there were languages that were "purely" functional, or "purely" logic-oriented. But today, most commonly used languages are "multi-paradigm." They incorporate ideas from FP, OOP, and other programming styles, but they aren't just one thing. When we say that a modern language is a functional language, or an object-oriented language, usually we mean that it's "mostly" functional or "mostly" OO.)

In general, when you're doing functional programming, you think about "functions" as the basic unit of the language. Functions can be passed around like variables, and you can assemble other mega-functions out of functions. If you wanted to sum a list of numbers, you wouldn't use a for loop. You'd use a special function called a reduce that applied the add function to every number in the list.

add(1, 2)
=> 3
sum = reduce(0, add)
sum([1, 2, 3])
=> 6

When you're doing object-oriented programming, you think about functions as being attached to data. Instead of having an add function that operates on two numbers, you make every number have an add function be attached to it. Or every cat have a meow function attached to it.

3.add(4) => 7
cat.meow() => "meow!"

Different styles are suited for different things! For example, if I'm doing math, I usually find functional programming easier to think about. To me, add(1,2) is simpler than 1.add(2). But if I'm doing other things, I often have an easier time with object-oriented programming. It's easier for me to think about a cat meowing than about a meow function that takes a cat.

Everyone has their favorite style of code, and every language implements these paradigms differently. That's why there are so many definitions of FP and OOP out there! Let's say that someone really likes Haskell. They like it both because they can define functions in terms of other functions (which is a FP thing) and because it has an awesome type-checker (which some, but not all, FP languages have). Because they love Haskell, they love functional programming. But when they talk about functional programming, they often talk about the things they love about Haskell's version of it, not functional programming in general. So people talk about FP as about "immutability" and "type checking" and stuff like that, rather than "building functions out of other functions," and everyone's definitions get confused. :(

The same thing happens on the OOP side! Some folks love using inheritance to organize their code. Inheritance is more common in object-oriented languages than it is in functional ones, so people talk about inheritance like it's necessarily an OOP thing. But! There are also object-oriented languages that don't do inheritance (Rust, arguably). And Haskell's "newtype deriving" isn't called inheritance, but it's basically inheritance. Similarly, just because we think of static type checkers in FP more often, there are totally FP languages without them (Erlang, Elixir) and OOP languages with them. (Java).

People say a lot of things about OOP and FP. A lot of the time, it's to justify why they think that one of them is better than the other. They'll say things like:

OOP is easier to understand in complex systems because objects maintain their own state. Stuff that's far away from the object I'm working with can't affect my code.


FP is better than OOP, because immutability means that I never need to deal with state bugs.

These statements tend to get truer if we sprinkle phrases like "for me" and "usually" through them. So we can translate the above statements into:

I usually think that OOP is easier to understand in complex systems because in my style of OOP objects maintain their own state. Stuff that's far away from the object I'm working with usually can't affect my code.

I think FP is better than OOP, because in functional languages with immutability, I never need to deal with state bugs within a single function.

In general, I wouldn't sweat the difference between FP and OOP too much! Instead, I would look for what aspects of a language make you feel more confident in the code you're writing. When you're looking for teams to work with, seek out people who value those aspects! You'll find each other's code much easier to read than code written by people who value different things.