Describe the difference to be more simpler

Describe the difference to be more simpler

Protip: you cant

Other urls found in this thread:

youtube.com/watch?v=IRTfhkiAqPw
youtube.com/watch?v=V6VP-2aIcSc
twitter.com/SFWRedditImages

Left are the methods of the object of the right

faggotry

On the left you have a patrician coder.
On the right is pajeet.

What you drew reminds me of an fsm.

>functional is procedural

>implying this is the real reason for oop
Data and function encapsulation is neat but it isn't the real reason for OOP
OOP is one way to achieve "high order function"
>I'm using "high order function" in a very broad sense so bear with me
It's all about treating function as regular variables
In C for example you can pass functions as arguments to other functions, return functions from functions, etc by using pointers
This is all really good but you can't create a NEW function inside another function and return a pointer to it
In Java this is trivial, you just wrap the function in a class, initialize a new instance of said class using a constructor, and now you can have a new function that didn't exist before
This is all very simple and Java programmers do that all the time without even realizing it
It's that easy
This is why having a garbage collector is good
>but lisp/haskell/etc have REAL high order functions
That's true, Java (and OOP languages in general) tend to be very verbose
That's a side effect of the OOP design
But it's easier to reason in OOP

It's a good compromise

>tldr
OOP is a way to have high order functions and pass and return functions as part of objects without a radical departure from procedural and structured programming

>procedural
suck_dick(op);

>object oriented
op.suck_dick();

You have no idea what you're talking about.

Notice how only the left mentions actual actions that movr the program forward.

Nothing you described has anything to do with OOP.

The left isn't procedural, it's functional

OOP also has methods such as withdraw, deposit, transfer, but it has them within classes which may be instantiated more than once. This makes it far easier to store state for large systems involving multiple actors and many disparate pieces of data of the same type (or class, if you will).

Additionally it offers the benefits of encapsulation, making programs more predictable and maintainable, and inheritance, allowing programmers to eliminate redefining identical behavior across multiple types of data/classes.

how not?

Procedural
>you have data type prescription
>you have procedures that work with data

Object Oriented
>you have class and its object instances
>methods are attribute and part of state of the class

What OOP means is really dimmed these days since procedural programming offers namespacing and associated methods that really just have implicit argument and OOP deviated further from Java where in JS or PHP you can rewrite the methods or class variable schema on runtime. Inheritance is basically still abstraction over composition that helps the language to solve type system. There is no real difference.

yes i actually searched up the difference between func/im/dec and the image is pretty vague (almost too vague)

I hate class-based OOP because I hate classes being used for dynamic dispatch, implementation reuse, and encapsulation, and I hate do-er types which exist only to house functions. Newer languages like Go, Rust, and Swift are far from perfect but are at least breaking these concepts apart from each other. These features should all be utilized via separate, first-class citizens.

>This is all really good but you can't create a NEW function inside another function and return a pointer to it
?????????
int func(int x) { return x*2; }
int main() {
int (*fn)(int);
fn = &func;
func(2) // 4
}

with some trampolines, you might could build something useful
listen more, talk less

}

>functional
op >>= suck_dick

That is just a pointet to a function that exists you autismo

>LISP
(suck-dick op)
>Forth
op dick suck
>perl
$=> __OP__
>APL
¢ π
>whitespace

Real debate

object oriented ideology not only treats women like objects, but also promotes piracy

really makes one wonder whose side C++ coders are really on

it's procedural.

Umm, the two are not comparable.

Fix

oop is more like this:
CustomerFactory
CustomerBase
Creature
Person
MoneyProxyImpl
CurrencyConverter
IDepositable
IWithdrawable
ICanHaveBankAccount
AccountBase
BankAccount
and on and on

you sound like a student without any experience

OOP is just forcing single dispatch for all functions.

Function, method, same difference.

I would be fine with just a syntactic sugar to write y.func() to better structure my code without bringing in extra poo.

This is pretty accurate.

this

Sadly this is my experience in the corporate world.

t. never wrote an OOP application

I am also in the (((enterprise))) world and the absolute worst code is done by people who clearly do not understand OOP as a principle (like the fag you responded to) and instead write the business logic procedurally, splitting the code across methods every 500 lines, if at all

Okay well here's a guy who understands OOP well and still shows why procedural is preferable in many cases:
youtube.com/watch?v=IRTfhkiAqPw

He ever goes as far as to convert an entire NES emulator from OOP to procedural to prove his point:
youtube.com/watch?v=V6VP-2aIcSc

>g∘f
>not f∘g

Right are the arguments of the procedures on the left

That's imperative vs declarative

in the first video the guy is using low viewcount youtube tutorials as his examples for "proper" OOP code. he's shitting on UML overall because it's been used for a very trivial problem. he goes as far as calling a few nested if statements "a lot of complex logic".

>He ever goes as far as to convert an entire NES emulator from OOP to procedural to prove his point
won't even bother watching that one but ask yourself if something like an emulator of an old 8-bit video game console is something you would model using OOP in the first place

yes, there are cases when procedural code is the better approach to a problem, but people using OOP wrong or when it's not the best solution, does not make OOP bad or useless