FP vs OOP | For Dummies 

I strongly object the idea that allocating memory to local variables is a side effect. If that were the case, NO programming language could achieve zero side effects. Local variables are stored on the stack of function calls. Once the call is done, all local variables are wiped off. "Side effect" means causing changes to variables outside the scope of the function (by means of assigning different values to global scope variables, or member attributes of input parameter). Thank you for the video but please improve the example.

... That's simply not how it works. Creating a new variable inside the function itself that doesn't even get muted afterwards is not a side effect. Both functions were functional approaches.

Memory increase doesn't count as side effect in FP, otherwise, just calling a function would be a side effect.

A side effect would be mutating a global variable from inside a function, but since the variables defined are in the scope of the function, it isn’t really a side effect...

Well, as everybody has already pointed out the "memory side effect" error. I will add that the concept of not having to write the same code over an over again is called ABSTRACTION, and it's a feature that literally every single paradigm has, it's not a thing of OOP. The funniest thing about this video is that it's said to be "for dummies" lol, should have instead been "by a dummy"

Using variables inside a function is not a side effect. Side effects are effects that could change how the function works depending on external factors, like network, filesystem or random memory access.

Sorry but in the attempt at simplifying the topic ambiguity has been introduced. The side effects highlighted in the first example are only there because the scope of the variables extends outside the function, which was not explained . If the variables in the imperative example were declared inside the function their 'side effect' would be virtually zero. Yes memory would be used but memory is also being used to store the input values x and y as parameters. There is a good explanation of OOP but using classes is not the means of implementing OOP. However, the answer is to the question is sound, one paradigm is only better than another in specific cases. There is also the possibility that a blend of both might result in a better solution. Being aware of the strengths and weaknesses of both approaches is what is important. Finally, dark blue text on a black background is not a good combination for reading.

Hold on a second! Calling a function pushes the return address and the arguments for the function into the stack memory. CPU resolving the formulas like x^2 is also using some memory for temporary storage of values during calculation. Hiding it all from a programmer sounds more like a psychological trick to me, not as a technical solution for sure. I'd rather have openly declared memory usage as a variable than having it done secretly behind the scenes pretending there are "no side effects". Pushing everything into the heap or stack is no different. It is all memory anyway.

Instances of classes are nominally typed by a class, but inheritance is a relationship that exists between classes, not classes and their instances. So the `Dog` class might inherit from the `Animal` class, then an instance of a Dog class is also an instance of the Animal class. Inheritance creates a type-hierarchy (sub-types).

It is kinda mentioned in the video but I think it's important to highlight again that OOP focuses on object creation and inheritance. FP focuses on pure functions and isolating side effects (including application state). Since they solve different problems it's actually possible to use classes and mostly pure functions simultaneously. Other, different solutions to object creation, inheritance, and particular side effects like state management exist as well. Furthermore, it's possible to program in a 'functional style' in languages that mainly support OOP. And though it's extremely awkward and generally unadvisable, it's possible to produce object-oriented code in a functional programming language.

Composition can be used in functional programming to resolve second issue of repeat code

Don't local variables in functions usually get flattened in modern compilers?

It is nice having all this info in one video, but I will say it took me several years to understand this concept. I don't think I would have understood this as a beginner programmer because I lacked the knowledge and experience.

The functional side effect example is a bit janky but there are some compilers which still do variable assignment like that, I suppose. Here are my 2 cents: Both OO and FP are structured paradigms. Structured means that program flow goes along clearly noted boundaries. Unlike some languages in which you are able to do anything. The strictly structured nature of modern programing languages does not particularly protect you from creating a ball of mud, but it makes it a bit harder. The main difference between OO and FP is how the handle data. In a functional system you input the data to get the result, in an OO system you incorporate the data. Both paradigms let you easily create extendable applications. However FP does not handle changes very well. Subsequently, OO is designed to manage side effects but it can be less stable as a result. The mutability problem also brings into question performance. In general, stateless applications need to be fed with data which inevitably leads to extra memory operations which can incredibly costly without a well designed pipeline. OO does not have this issue. As for the real world. If you have a problem and need a robust solution, FP is the way to go. There are plenty such cases within a project. But generally speaking, again, in the real world, problems, solutions and desired outcomes change. Therefore, on the surface, OOP is the only viable option.

In the minute 3:37 you mentioned no side effects on computer memory when using functional approach however, I F# language and haskell functional approach does effect on computer memory for the sake of processing input data as per their explanation of how functional programming works. Your words had got me so close but I had to read and search for this piece of info just to see if I am in the correct paths. Dude thanks for your efforts yet I suggest full review and auditing your functional programming understanding. Peace 🙏

How does declaring variables inside the scope of a function qualify as a "side-effect"?!

Hmm, but when translating to assembler or machine code, won't there be side effects or the use of variables in the stack?

There is a very good chance that the two following codes will produce the exact same executable code: function f(x, y) { var sum = x + y; var sqr = sum * sum; return sqr } function f(x, y) { return (x+y)^2; } Compilers have optimizers that rewrite your code completely, in order to either store intermediate results when needed even if not explicitly written in the original code, or simply get rid of intermediate variables when they are not needed. Besides, OOP is more about encapsulation and polymorphism than inheritance. Inheritance is of course part of it, but the main point of OOP is to have a black box that does something with some input in a certain specified way, while another box will do something else with it, while both are called in the exact same way.

So removing variables, which diminishes readability and makes it hard to access values during debugging, is a great solution against bugs and for large-scale projects? I don't think so ...

i'm new to programming. so far i got this: oop is like a central management and distribution of methods and properties; but when you encounter vast number of unique and independent species in a world (like the world of animals), you are forced to describe each animal as a class(or may be you can expand the properties & methods of the parent class equivalent to the world of animals and make it available to all). good thing is that you allowed yourself to create (photocopy) n number of objects out of it, because of it everything got streamlined; when you change the definition of properties and methods of the parent class, all the objects reflect the changes beautifully(only you have to have a consciousness to understand that implications are on broader level) . oop asks you expand your knowledge on the subject from the beginning as opposed to functional programming which is problem specific (you can think for the new problem when it comes); I think its extremely difficult to keep the tracking of functional programming based project because it looks like a maze of independent functions somehow interconnected and working (useful for small requirements, definitely not for large problems). please correct me if my understandings went wrong!!

Smalltalk was built with Lambda expressions and it had first class functions. Smalltalk inherited many ideas from Lisp. On the other hand, Lisp (and Scheme) had extensions for doing OOP. So in practice, the distinction between OOP and FP is not always so clear.

good explanation on why OOP is useful for creating multiple objects of similar code though feedback for improvement, the video colors, text color to bg color could stand to be more contrasted. It's hard to see the blue font on the dark blue bg

Let me say something that is really cursed: My code often contains both functional and OO formats. This however has its own reasons. When calculating for example the distance between two coordinates you will use the Haversine formula. Using an OOP -language, would you create an object only containing the calculated distance, or would you give it directly to an edge of an ADT Graph? In these instances I voluntarily switch to functional programming, since the named mathematical formula IS isolated from the code to start with, but used like a package. In Java the Class Haversine would thus contain no fields but the methods Haversine and Archaversine which both only return values. It can therefor be declared as a static Class. This approach could be due to a background with functional languages before taking a step into OOP. So what do you think about that "hybrid" Code?

You made me subscribe you so quick..! Thanks man.. you cleared 02 doubts.. FP and OOP & Method vs functions.

i'm new to programming. This was the best well-spoken presentation with visuals. thank you. i want to learn more about programming one day so that I can also be arrogant with the rest of the programmers on programming comment sections as well.

As soon as the imperative example was given as an example of non-FP function i just tought "oh these comment section will be ruthless". I wasn't quite correct, but yeah, people were quick to point it out :D

The dark blue text on a dark grey background is a little hard to see.

Nice explanation and comparison. The developer's favorite refrain: "It depends". :)

what if we could reconcile the two and perfectly control spammed blueprints at high speed with no side effects and always achieve the result desired?

You can totally apply Functional Programming within OOP, I mean if you need to get the sum_squared, there is no reason to not apply the ideas of functional programming

A Struct and an array can accomplish the same thing as the OOP did here to create a small database of farm animals, OOP isn't needed.

Terrific graphics and presentation.

I had been a good idea to see how long is the code for this farm example by written in both in FP and OOP, asumió the case scenario of multiple different & similar animals coming in to the farm.

Well explained. Thanks 👍

Thank you so much for the simple explanation and very-well illustrated video!

Amaizing video! Thank you!

Imperative programming (OOP) tells the computer how to do something, step by step. Declarative programming (FP) tells the computer what to do, without specifying how to do it.

1:59 ^ is xor

Thank you man! properly explained and i got OOP principles better))

Crystal clear explanation.. Thank you.

I laugh so hard at the function variables part.

One small feedback, text colors are too dark over the dark background and it makes it quite hard to read

Using Dark Blue on a black background was a bad choice. Have to crank my monitor brightness just to see the text and I'm still leaning in.

Great explanation, detailed yet easy to follow. I look forward to seeing more of your videos. Keep it up!!

Perfectly explained. Thanks literally. Good work 👍

Unfortunately the example of side-effect in this video is incorrect. This is not side-effect since sum and squared are local variables and they are not changing any external state. In fact it is recommended to program like this to make the code easily readable. To make one liners like in the example is also bad approach. It works for calculating a simple square but real life functions are way more complex and can't be written so simply. In this case if sum and squared were global variables, then it would be considered side-effect. And side-effects are not always bad, sometimes functions do need to change external states.

It would be interesting to see how the dog example would typically be done using functional style only. How is the state changed in an acceptable manner in FP, nobody ever mentions this

This is so good explanation!!!

Can you make explanation on how Objects/Classes are actually working - meaning...the functional bare bones behind the abstraction? Everybody explains pointers with memory diagrams but nobody cares to elaborate on internal logic behind Classes. Which I find very useful for understanding the concept and use.

Didn't see the point in continuing after his initial description of local variables causing side-effects was blatantly wrong.

thank you for the video!!

Would Please add procedure-oriented programming ?

It's best to have both in one function object like with C++ lambdas or function-objects.

From my point of view there is a reason for intermediate variables, and in fact it has to do with the intermediate variables in a function actually being used for debugging purposes. Let's a a function actually has ten steps. Having intermediate variables helps the programmer to step through each step and validate the variables as they are being processed. If there are conditions within the function, such as IF step 2 results in a value greater than 0 THEN do Step 3 like this, otherwise do it like that, then having the intermediate variables for debugging is actually helpful, and without them debugging would be more difficult, not easier. So I'm not sure I buy the argument that functions without intermediate variables improves debugging. At least not in all cases. Where the function is executing a simple formula, then yes, ok. Otherwise, not so much I think.

Ok, so, completely an infant in regards to these matters. It's why I'm here. I'm 3:37 in and see that the computation is made and returned without creating additional variable names to store, calculate the result, then return it. However, to say that "no side effects" makes me scratch my head. Obviously x and y are variables and they are stored and acted upon as well as the "return" value has a place in memory as well right? I could see how the functional method would be cleaner and I'd assume faster, etc.... I like the style for it's readability alone and of course, less code.

good content, but the color of the font makes some text almost impossible to read

It would've been useful to show the farm game example approached in OOP as well as FP, to actually see how they would differ. No programmer would just write each new animal from scratch if they were using an FP approach.

Combination of dark blue text on black background is not a very good mix for reading, and for youtube compression. Compression just crushes this colors together making it hard to read. Even if it looks good in editing software it doesn't mean that it will look good on the internet with compression

why didn't you show us the functional version of the farm??

The basic idea of OOP is not a blueprint but messaging. The communication between components of a program.

This...doesn't feel right. Something is off.

I don't understand the use of classes, I always just used structs in c, does that I'm a oop programmer?

3:15 beyond your overly-simplistic “side effects” variable-setting example, there may be a problem with how you are naming methods at your corporate dev job that may be causing ongoing development issues and on-boarding problems

Dark blue text on a black background. Interesting choice.

It's a good video, but it leaves out some crucial things like mutability-immutability and polymorphism.

Breaking down the steps in to two is not a side effect. It is just cleaner coding.

Thanks, you explained it better than other videos on this topic!

What if I need a new type of object which is a Monster dog object oriented programming will fail but functional programming can do that quickly using composition

Superpower: using both FP and OOP together.

Very bad example in the beginning. Although there wont be any named variable in squared_sum function in single line calculation example, (x+y) will be stored somewhere in in memory before its squared. So as everyone commented as long as the intermediate variable is not global, both functions will have same memory impact. Also on the OOP part the primary reason given is redundancy, but we can do functional programming with reduced redundancy (which might be tightly coupled that we would like).

Why didn't you explain the farm example with FP style??

06:36 Dumb question time: Why would you create objects when you can use indexed variables instead eg dogs[0] = ("terrier", "Rusty".... etc) and then iterate over all dogs; dog_breed[dog] = dogs[dog][0], dog_name[dog] = dogs[0][1] ...etc.

not to be obtuse, but what you mean then is to put objects and then operate?

The font is really hard to see

What about procedural?

I think the text colour should be changed for better contrast. Anyway, nice video 👍

There are already too many comments about "variable = side effect is wrong", so isntead I would disagree with OOP example against FP example comparison. At first I thought that so called "Blueprints" talk will be about inheritance, but it's just about classes. And there's no difference between OOP and FP, there are custom data types or records in functional programming. I believe F# or Scala support constructors, or you can create a simple pure function which accepts a bunch of required arguments and returns a new Dog record with initialized attributes, so it's the same one-line way. As game developer I can say that real reason why FP doesn't fit well in games isn't because of some language stuff, when you need to start each animal from scratch (even the same one), but because game is by nature requires a lot of state which mutates over time and which often queried from different places, and also because games have strict performace requirements, so immutability in most cases isn't possible and side-effects are essiential.

Great video mate! Very clear examples with good visuals and nice production quality.

2:20 define squared_sum (x, y): return (x + y) ^ 2 No variables, WTAF are you talking about?

This is epic

People confuse functional programming with functional-reactive programming and functional UI frameworks. Functional programming is a paradigm that predated OO, it was used mainly in the 60s and 70s. A functional program is just a giant hierarchy of functions which executes continuously until all the functions return. In pure functional programming (which is more of an ideal than an actual programming paradigm) there is no persistent state, only local state. Just functions with inputs / outputs but no side effects. As the functional paradigm evolved it became clear the ideal of pure functional wasn’t practical, and programs came to rely on more persistent state, which was usually global, though could also be non-local hooks. There were alot of problems with the functional paradigm which OO helped fix… The fragile top-level interface is one issue - when your program is just a giant function hierarchy, any change in an interface near the bottom tends to ripple up to the top, this makes changing the code difficult and require extensive refactoring. Different parts of the program accessing shared state meant extensive lifecycle management and/or locking became necessary. This state was also not encapsulated - and the data was separate from where it was used, this increased complexity. It leads to a spaghetti-code situation as the codebase grows in size / the amount of this persistent state increases. OO fixed these problems to a degree with encapsulation, lifecycle management, and polymorphism, but introduced a new problem - encapsulation means that the distributed local state is now persistent, so we now you have to go to extra lengths to maintain consistency. There’s also alot more persistent state to deal with. Functional reactive uses data bindings to drive updates to the distributed state of a graph of objects, to bring their state into consistency. These components are objects - regardless of whether your UI framework provides a functional API for creating them or not, behind the scenes they’re objects. Functional reactive programming is basically a remedy to problems inherent in OO. It is not dispensing with the OO paradigm, without OO it has no useful purpose. And it’s a completely different programming model than that of traditional functional programming. The word functional in functional-reactive is referencing the fact that functional-reactive programs glue together components into a cyclical data flow and drive updates, doing functional transformations at different points along the way. State also remains consistent between components, which connect together seamlessly, similar to traditional functional programs - you have persistent distributed state, but it no longer behaves that way. There’s also this idea that state should be immutable and the data structures should have value-semantics, and languages have been adding support for this. State behaves more like a local copy this way, you don’t end up with bugs from multiple threads accessing the same data during the update cycles. With FR we’re augmenting OO with all the best characteristics of traditional functional programs - we are getting the best of both worlds now. Functional UI frameworks are leveraging the ideas in functional reactive and providing a higher-level functional interface for creating UIs. The isn’t a reversion to the functional paradigm, or the introduction of a new general programming paradigm- you can build up a framework to provide any kind of API you like, we even have frameworks that allow you to construct your UIs using a GUI, but these frameworks are still just decorating a composition of objects and managing that state behind the scenes for you. That works within the limits of what the framework can create - it’s not a generic programming paradigm. Also… Javascript has its own unique reasons for not wanting to use objects, but that’s a language issue. Better designed, modern languages like Swift have powerful data structures with value-semantics which work very well in these contexts. Functional reactive is serving its useful purpose when combined with OO. Its purpose is to keep distributed state consistent. People who argue for choosing functional over OO… don’t really understand what functional reactive is and what makes it valuable. I’ve also seen an increasing number of programmers arguing for reverting to the bad programming techniques of the 60s and 70s lately, which is not good. I’ve done a little work in a codebase written by some devs resuscitating the old functional paradigm... I joined their team to help out because they were falling behind other teams. Looking at the code.. it became clear why - they’d just created a monolithic procedural mess in an attempt to be functional, convinced they were being innovative. Their code couldn’t adapt to our new use cases… it’d take 6 months to clean up the mess.

why I can't just create a function that creates animals?

This is so good! Can you make a video on procedural programming too?

the dogs are all Beagel hahah well thanks for the vid I learn a lot

I see that you've taken a lot of flak about side-effects. Nevertheless, if we concentrate on the OOP portion of your video, I think it is EXCELLENT -- a wonderful and much-needed explanation in plain English that demystifies the creepy, sententious, ivory-tower jargon of OOP itself. A great public service for the novice!

F(x) = x + 5 -> high level calculus

your blue on black is killing me

Sorry, side effects are long lived variables, database operations, sending emails etc... not memory allocation. All running software allocates memory This is why a pure FP solution is more theoretical than actual outside of mathematics. The real goal in FP in real life is to be aware of the side effects so to reduce their occurrences in your code in a logic and consistent manner. This will allow your code to evolve and take on new requirements with little or no further side effects.

Good video.

That square of sums example feels contrived...

This is why dislikes should be visible.

Nice

That was a really clear explanation, thank you!

To all those who are pointing out the fact that the example I used for explaining side effects is not accurate in today's compilers: I am aware of this, however my intention of this video was to lay these concepts out a simply as possible to the audience. This video was a school project with the assignment being to explain a complex topic as one would to a group of 5th graders. Regardless of whether or not modern compilers behave like this, it was irrelevant to me. All I cared about was getting the point across of what side effects are. (For dummies, and dummies only) -Thanks for all the support

142k views. 4k likes. 287 comments. Something ain't mathing

I think defining a local variable cannot be a side effect. Side effect happens when we change global variables.

Brother, C language is also a procedure oriented programming but it does have or rather I would say it heavily relies on side effects, without side effects a procedure oriented programming cannot exist ! Consider strcat helper function (string.h) which lets your first argument's value changed, that's a side effect !

To play devil’s advocate a little bit, storing the result of calculations in variables isn’t exactly idiomatic functional programming since it’s more imperative than declarative so I kind of see what the thought process was but it was explained rather poorly

I disagree that a pure functional function cannot use temporary variables on the stack. A pure functional function doesn't affect and isn't affected by global state. Side effects can occur when a function reads from and/or writes to global state. This can be shared global memory, memory mapped peripheral, IO, etc. This means function A might not always return the same output given the same input and a call to function B, might affect the output of function C. Some functions lack inputs and/or outputs. Order of function calls matter. The entire system can become a complex implicit state machine. A pure functional function can use stack (or even heap or static memory) as long as it doesn't affect or is affected by global state. Real world programs have external inputs and outputs and can therefore never be pure functional and require non-pure boundary functions. You can, however, implement all the logic in a pure functional way and put all state in data structures. If you count time/CPU tick as part of the global state all functions have a side effect as they take time to execute and delay functions do this intentional. Many systems have timing requirements. Even a simple user interface, but also real time control systems.

Clear explanation, thanks !