OOP vs Functional Programming

Let's compare, contrast, and debate these programming paradigms. 😇

Comments

[Tom VanAntwerp]

The thing I love about JavaScript is how easy it is for me to have a bastardized combination of OOP and functional.

Yes, I'm an awful person. ¯\_(ツ)_/¯

[Elliot]

Honestly I really like this about JavaScript as well! You get some good parts of OOP and the best parts of FP and the worst parts from both :)

[Patryk]

I routinely mix both styles in Python as well.

If you look at the way the language is designed, I think it makes a lot of sense. Iterators, map function, filters, generators... They mesh really well with classes.

[Jonathan Apodaca]

Err on the FP side, and then encapsulate your data-structures with OOP. Why not both?

[Dakota Lewallen]

My thoughts summed up super concisely. 👍

[Jacob Herrington (he/him)]

@avdi gave a good talk relating to some of these ideas at RubyConf in Nashville.

I'm not functional aficionado, but I tend to think OOP and FP are not mutually exclusive. A good example, in my opinion, is the Actor Model which (as I understand it) fits into both camps.

From the sidelines of this conversation, I kinda wonder, "why not both?"

[Kasey Speakman]

A traditional Actor is almost definitionally an object with private state and public behavior via messages. But to your point, there are functional adaptations which, instead of having private state, are provided their previous state and a new message to process, then return a new state and side effects to execute. MVU update function is exactly this from a dev perspective. Although from a runtime perspective it is usually still hosted inside a traditional actor/object. Because of our heritage from the von Neumann architecture at a low level.

[Yaser Al-Najjar]

OOP:

A fancy way of programming to represent real aspects of an entity in programming, say a "car":

src: lynda youtube.com/watch?v=NUl8lcbeN2Y

And yes, everything referenced gets changed when it's passed by reference, unless you pass it by value... cuz it follows the imperative programming paradigm.

def my_function(car):
    car.name = 'Hyundai' # changes the original object name

c = Car(name='Kia')
my_function(c)
print(c.name) # prints > Hyundai

Functional programming:

A safer approach than OOP that is a bit related to math (its origins is from the lambda in calculus).

They key here is "immutability", where every function should create a new object, and not change (mutate) the passed object... aka "declarative".

const numList = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
const result = numList
               .filter(n => n % 2 === 0)  // here a new object gets created
               .map(a => a * 10)             // and another one here
               .reduce((a, b) => a + b)   // and another

That being said, here we have created 4 different objects.

Is any paradigm better than the other?

No, just use the right paradigm in the right context, it is very common to write OOP in Python and to write functional in JavaScript.

[Raunak Ramakrishnan]

FP and OOP mean a lot of different things to different people. This is something to keep in mind while discussing.

Here's why I like FP:

• Immutable data structures
• Pure functions (without side-effects) which can be easily tested
• Building complex software by composing functions
• Making illegal states unrepresentable using the type system
• Algebraic data types and pattern matching

There are different types of languages in FP. For example Haskell is lazy by default and this allows you to easily construct some types of programs but makes it much harder to reason about performance. OTOH, Ocaml is an eagerly evaluated language with not as powerful type system as Haskell but it allows to write programs which are competitive in performance with Java and Go.

OOP as envisioned by Alan Kay involves message passing and lightweight programs (like in Smalltalk). What we use in Java and C++ is quite different from his original ideas. That said, I have heard that OOP is useful in GUI programming. Languages like Java and C# have many good properties which make it easier for building large projects with large teams. There are design patterns to efficiently express common idioms.

FP, OOP, Imperative programming, logic programming all have their place in a programmer's toolbelt. Some concepts lend themselves to using one or the other. We should view them as tools to be used as required and not as the one true way of doing things.

[Ryan Faulhaber]

I apologize in advance for my rambling response.

I feel like any discussion of OOP has to be qualified to some degree, because often when I hear "OOP" they're usually talking about writing code using Java or C#. So although this is kind of a strawman, I think that the OOP of Java and C# is incredibly rigid and antiquated, and I don't think it's a coincidence that modern languages have abandoned a lot of features from these languages, namely inheritance (and Java even has lambda functions now! Quelle horreur!). These languages also promised far more than they delivered, and in languages like these, a more "object-oriented" solution would be far more contrived when a single or couple of functions would suffice.

But I don't think OOP is all bad! Things like interfaces are great in statically typed languages, and they make languages like Go and Rust very generic. I do think Smalltalk does OOP better, though, and is what OOP should really strive to be.

I think functional programming is hard, and that's its biggest con. At least given the way I was educated in computer science, there's no "easy" approach to learning functional programming. That said I have gotten much much more mileage out of code that is more functional than object-oriented. It's way easier to write generic, simple, and testable code when your code is just a bunch of simple functions that you can compose and build your way up to more complicated behavior.

I think languages like Rust or Go strike a good balance for most uses: static typing with functional features. Sometimes you need stateful objects, and so you can write a struct with methods, but you're not obligated to (in fact, when it comes to a language like JavaScript, the language I write most, that's my rule of thumb: do I need state? if yes, I'll write a class, if not, it's a function. Most of my code lives in functions).

Finally, I do think functional programming is wildly underappreciated and has a lot more to offer than people give it credit for. Immutability has saved my skin more times than I can count, for example. I think a lot of languages could benefit from adding more functional aspects, honestly.

[HS]

We'll let's just say OOP as in Java and C# an take it from there. Even though Alan Kay did say he regrets calling it OO and wanted something like message driven and ended up with some explenation of Actors ppl call OO anything with classes. Late Armstrong did say Erlang was OO more than others and quoted Kay but people that use Erlang will smash your head if you call it OO.

[saint4eva]

C# and Java are very powerful and popular programming languages

[Iven Marquardt]

Does it really matter what paradigm you are a disciple of? I am interested in passionate programmers who know their craft and from whom I can learn something.

[Jonathan Apodaca]

Yes...just like Rust! RIIR

[Rohith Gilla]

OOP vs FP
Do you think the programming paradigm you use effect your daily life, like in psychological way. The way you think, plan and everything.
This may be an interesting view point too I feel.

[David Wickes]

What's an object?