DEV Community

Cover image for Functional VS Object-Oriented Programming

Functional VS Object-Oriented Programming

Kurt Bauer on August 26, 2019

The Gist Different programming languages have different features, or paradigms, that can be used to classify them. Today we'll take a l...
Collapse
 
robconery profile image
Rob Conery

Hi Kurt. Listen... this:

Object-Oriented Programming uses Classes, objects and methods to achieve it's lofty goals. Functional Programming on the other hand makes use of an army of pure functions and variables to to build a larger whole.

Needs some work. I encourage everyone to explore and to find out whatever thing scratches their itch but OO and FP are not differentiated by classes, methods, objects and pure functions. Yes, these are a few differences but I would encourage you to look deeper (or, if you already have, to describe those differences here) as there's a world of different thought in there!

Currying, for example, is mind-blowing as are functors and monads. For instance, dig this:

const nightOut = who => what => where => {
  return `Out with ${who} having fun ${what} at ${where}`;
};

That's a lambda in JavaScript which is "Curried" - instead of 3 arguments to a single function we've chained together 3 functions with a single argument. This allows reuse and composition:

const funTime = nightOut("Dancing")("wife")("Club 9");

The interesting thing is that I can capture/reuse these things functionally thus:

const dancing = nightOut("Dancing");
const dancingWithWife = dancing("wife");
const funTime = dancingWithWife("Club 9");

This is just the surface of functional programming and all the interesting things you can do with immutability and functional composition.

Monads (which you can arguably think of as chained promises) allow you to transform data within a transactional process. That's really the thrust of functional programming: data transformation that doesn't involve changing other data (side effects).

OK - I don't want to sound like a jerk! There's so much more here and I encourage people to look deeper :).

Collapse
 
stereobooster profile image
stereobooster

This sounds a bit misleading.

Yes, currying is nice, but there is nothing magical about it. You can achieve the same with objects ¯\_(ツ)_/¯.

all the interesting things you can do with immutability and functional composition.

Immutability is not something that adds capabilities to the system it rather restricts capabilities (you don't have the mutation). It is a trade-off. Developer agrees not to mutate things (as the result they can worry less about some edge cases), but the same time you need more memory (not necessary much more) and new tools (for example, lenses). There is a middle ground, like local mutation allowed and global mutations prohibited, for example in Pony language.

Collapse
 
krtb profile image
Kurt Bauer

Absolutely not, Rob, not a jerk at all! I always value opinions backed up with evidence, it helps us all learn and grow. Personally I know that I actually need to spend more time looking into currying and monads, and it seems like that information would have helped me to write this article. Thanks for providing so that others who read this can reference your comment and keep on falling into the beautiful rabbit hole that is coding.

Collapse
 
ssimontis profile image
Scott Simontis

I also find OOP enticing when we don't understand the problem domain at all. We start creating objects, they start interacting, damn we're good! Then as you learn the problem domain, you realize that your model doesn't really make sense compared to how it exists in the domain. Now you have to do some major refactoring to match the domain accurately, or you just keep on creating more objects and pretend nothing is wrong.

Functional programming requires you to have a very clear understanding of the problem at hand (at least in my opinion). I also think that sometimes working "insides-out" is really effective to force yourself to get coding. By the time you start stringing something substantial together, you have a pretty good idea of what functions form a good public interface to your program.

Collapse
 
krtb profile image
Kurt Bauer

haha, yessss, this is exactly what happened to me when I built my first large rails project. I created more objects to plug the holes in a sinking ship and then gave up and how to do a lot of refactoring. But it's also spurred me into looking at different back-end languages like Node and Golang, to see how forgiving either one can be when hitting that wall. Still working through them though. Have you found an OO back-end language where you feel it's easier to do that refactoring?

Collapse
 
ssimontis profile image
Scott Simontis

Hmm...not quite. C# is what I have been using for the past 7 years straight and is the language I know best by far. I'm so used to it, it might be difficult for me to objectively compare things. I think the implementation of generics is really solid, which reduces the number of objects I have to write. My only qualm that is language-specific is that functional programming constructs look really weird and take a ton of code...10 lines of F# can take 100 lines of C#, and the C# code looks hideous with generics everywhere.

I think that having a base Object class inherited by all objects is a huge mistake and brings no value whatsoever. All it does it ensure that I need to do a ton of defensive type checking and reflection whenever I try to compare two objects. There isn't really any behavior that belongs on that level that is applicable to every single object. I believe C++ does not fall victim to this base object mentality, and I have been studying C++ lately to try and get back into embedded/AI stuff.

Ironically, I have also been looking into Ruby because I have heard it is a developer's language and a really enjoyable experience. I have not gotten to the point of appreciating much of it, but I am going to keep trying, dammit!

I also played around with Racket (a Scheme dialog) and found myself intrigued by LISPs. Blurring the line between code and data is pretty neat, but sometimes it's so abstract that I have no idea if what I am doing works. And no way in hell I could explain the code to someone else confidently.

Honestly, maybe TypeScript? I like the typing because it prevents a bunch of stupid errors and guarantees some consistency between objects. It's such an easy language to hack around in, but most uses these days seem too primitive. Why deal with Express and write the same middleware that a million other developers have written to? Why not abstract that all away to a more mature back-end runtime? I guess that's the downside to needing thousands of random dependencies to accomplish anything, big building blocks are hard.

Collapse
 
cescquintero profile image
Francisco Quintero 🇨🇴

This a good post to show pals the differences between these two paradigms.

Collapse
 
krtb profile image
Kurt Bauer

We're just all out here trying to get a handle on a wide range of topics, myself included. Glad I could put together some information in one place for you and the gang. Y cómete una arepa de choclo con quesito por mi porfa, tengo una tía Colombiana en Chile qué me las haćia!

Collapse
 
cescquintero profile image
Francisco Quintero 🇨🇴

jajajaj la arepa de choclo es popular en antioquia. Yo vivo en la costa norte, acá comemos es arepa con huevooo :D

Collapse
 
combinatorylogic profile image
combinatorylogic

It does not help to keep calling FP "declarative".

Functional programming is just as far from anything truly "declarative" as OOP.

Both paradigms are very low level and do not really help to adequately represent the complexities of the real world problems. More declarative paradigms fit much better, but for some weird reason people keep comparing FP to OOP, as if there is nothing else out there.

Collapse
 
euler2718 profile image
John Corley

Ha this is true. Probably, OOP and FP are polorizing? There are a lot of ppl who will really dislike one or the other while less so about something more procedural?

I don't know but you are exactly right.

Collapse
 
stereobooster profile image
stereobooster
Collapse
 
krtb profile image
Kurt Bauer

Thanks for the heads up! I did some more research after you mentioned this and found a great article that talks about achieving "pseudo-encapsulation" through the use of factory functions and closures in JS for example. Really cool stuff

Collapse
 
stereobooster profile image
stereobooster

Why "pseudo-" though? It can hide variables the same way as class private fields.

Thread Thread
 
krtb profile image
Kurt Bauer • Edited

Hmm, well according to his article he was saying it wasn't natively supported, in JS at least

"By far one of the biggest anomalies of JavaScript is it’s inability to natively support encapsulation.

The scoping system was introduced with TypeScript, which is a superset of JavaScript. But unfortunately its not a clear victory yet since, while it does give you a warning, TypeScript code still compiles and runs even when you access the private variables."

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

The two are not opposed, just different, between oo and fp is ofp.

Collapse
 
krtb profile image
Kurt Bauer

Thanks for pointing that out Adam, I made sure to put in a little disclaimer at the top of my article and linked your profile (let me know if that's cool, I could always un-link it!). And thanks for giving it a read (:

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

Ha that's ace, you sir are a gent.

Collapse
 
olvnikon profile image
Vladimir

I would also mention that FP encourages to handle "null" and exceptions in a different way using Maybe (or Option) and Either monads. The concept is called "Railway programming".

FP encourages lazy calculations. For example, IO monad doesn't run the effect until the very last moment. The same with Future (FP Promises).

FP has a different approach for reusing the code. For example, lenses can be applied on any object. Atomic functions can be composed and used to map data.

There are more differences but these came up in my mind besides things that were mentioned in the article and in the comments.

Collapse
 
heisanbug profile image
heisanbug

This is very helpful. Thanks:)

Collapse
 
krtb profile image
Kurt Bauer

You're welcome Vijay! Your comment gave me a nice little push to keep writing, thank you for reading it 🙏🏽

Collapse
 
basickarl profile image
Karl Morrison

Worst blog post ever, why did you not show the functional programming example of the oop example?

Collapse
 
jwp profile image
John Peters • Edited

All good OOP winds up containing functions that do only one thing anyway. There's no difference in functional compostion and OOP. Non-OOP people just haven't realized that yet.