So Object Oriented programmign is complete ass

So Object Oriented programmign is complete ass

Whats the verdict on functional programming

Other urls found in this thread:

en.m.wikipedia.org/wiki/Cargo_cult_programming
m.youtube.com/watch?v=0N_RO-jL-90
twitter.com/SFWRedditImages

reddit meme

2/10

to early to tell. I love hoon though

What?

By saying it's a meme you're actually telling us
>it's too hard for me, I don't understand it, should I try functional programming?
Try Scratch, you gonna like it.

he didn't say its a meme, he said its complete ass, which is true.

What did I do to you? I didn't say that. Stop being mean

about the same

>It's ass
Wow, what a great argument user

Wah it's so haaard

its not hard though, its ass

>learned OOP first
>resort to imitating OOP when using C

how do I acquire procedural brains?
what does good looking C code even look like?

OOP is truly awful, I don't see how anyone could disagree with this.

Functional > procedural >>>>> shit > OOP

Check out the Linux kernel.

You are complete ass. OOP is a meme. A funny name for an approach used in pretty much every paradigm. The difference is in how your code looks, not in how it achieves the goal. You made no argument against OOP. You came here to cry and find other losers to cry together.

anything besides pure lambda calculus is truly awful, I don't see how anyone could disagree with this

You're trying too hard man

The verdict is OP's execution.

Most of linux kernel code functions accept an argument with state, which is exactly what C++ objects do (passing _this_ pointer), and C++ is considered OOP.

I haven't even started.

Linux drivers interface is a classic case of inheritance with polymorphism.

>Most of linux kernel code functions accept an argument with state
doesn't every function accept an argument with state? what does an argument without state look like? why pass it in if the state doesn't matter?
if using functions is OOP, then I think C is an OOP language

Once again, what a wonderful argument senpai
You can prefer a different style of programmation sure, but you can't honestly be cucked to the point of believing that one has serious advantages over the others. They all do the same thing, only by taking different paths. Is that also too hard for you to understand?

Well, sin(x), for example, does not accept a state.

But if you have a custom math library, and you create an instance of it using

Math *math = create_math_library();

and then you call sin as

double result = math_sin( math, x );

that definitely would be passing state. OOP is more than passing state, but the line is too blurry be able to clearly say that some things are OOP and some others are not.

>sin(x), for example, does not accept a state
then how does it know what result to return if it doesn't know the state of x?

You have a very serious misunderstanding of programming paradigms and arguments between them if you genuinely think this

State is a bunch of data grouped together, designed to be used in multiple class to one or more functions. x in sin(x) is not a state.

in multiple calls*

So if x were a more complex data type it would be considered a state? It's feasible that many calls from multiple functions would take some set of values to work with.

It sucks cock

No, it wouldn't be. You are not intended to pass the same complex value to multiple functions (even if you can - this is not about what you can). If you are intended by the developer of those functions, then yes, it is a state. If you have a random number generator, and you pass seed as a single integer by reference to the random(seed) function, then, yes, it is a state.

> If you have a random number generator, and you pass seed as a single integer by reference to the random(seed) function, then, yes, it is a state.
I'm now more confused than I was before.
So what matters is if the function is modifying the argument you pass to it?

sorry

No.

Okay, thanks, that makes sense.

I explicitly mentioned the part that is relevant twice. It's not modifying the argument. If you are incapable of figuring something as simple as that, me mentioning it for the third time is not going to change things.

Why does it matter if it's passed by reference if modifying it doesn't matter?
Every set of functions designed to take the same complex data type can be considered stateful?

>Every set of functions designed to take the same complex data type can be considered stateful?
You already asked that.

No, not quite, you yourself elaborated and said "(even if you can - this is not about what you can)" with regards to accepting the data type.
I'm going to take your answer as a yes, but it still doesn't sound right to me.

I think that in order to be a truly good programmer, you have to recognize the good parts of both FP and OOP, and use them to your advantage. For example:
- Have each part of the program focus on itself, and communicate clearly with the outside.
- Make units interchangeable via interfaces.
- Pure functions are easy to reason about; avoid global or file-level state, and prefer free functions over methods.
- Localized code is more concise and reusable.
These ideas can apply to every language, even down to C, and ignoring them is ignoring progress.

Well-structured programs that are sufficiently large will become object oriented in style even if not written in OO style explicitly

State is a bunch of data grouped together, designed to be used in multiple calls to one or more functions.
State is not a type. It is actual data, bunch of values.

What matters is INTENT. You are intended to pass seed, same data in memory, to multiple calls.
Passing by references does not automatically make passing data into state.

divideBy3(double argument, double &result, double &remainder);
divideBy5(double argument, double &result, double &remainder);

struct ResultAndRemainder{ double result; double remainder }

divideBy3(double argument, ResultAndRemainder &result);
divideBy5(double argument, ResultAndRemainder &result);

None of those functions accept state, because you are not INTENDED to be passing same values to them.

appendToFile(const File &file, String text);

This function does accept state, even if all File struct has inside it is a file descriptor, so the function does not modify the structure. The function accepts state because you are INTENDED to pass the same file to other calls to appendToFile() as well as to closeFile().

I disagree. OOP style means that you have a chunk of "god" data at the start of every function, and there's no reason why that would happen.

I do think many of the "benefits" of OOP, like encapsulation can be applied without resembling anything like OOP, maybe that's what you mean.

>OOP style means that you have a chunk of "god" data at the start of every function
are you high

what are methods?

>State is not a type. It is actual data, bunch of values.
Okay, so state is a collection of otherwise logically disjointed data?
>You are intended to pass seed, same data in memory, to multiple calls
Shouldn't your seed be different in order to get different values?
>The function accepts state because you are INTENDED to pass the same file to other calls to appendToFile() as well as to closeFile().
You lost me again. If you're intended to pass the same value to multiple functions, it's state?

Methods are functions that are required to have a parameter that is used to pass the state to the function. The word god is not applicable to the passed state, and there is no chunk, just one reference to state.

I do not understand you question. Please take some time to think about it more carefully and rephrase it.

>I do not understand you question. Please take some time to think about it more carefully and rephrase it.
What is an argument with state? How does it differ from an argument without state that is commonly used throughout the program?

I believe I already provided an explanation.

I do not understand your explanation.
Please take some time to think about it more carefully and rephrase it simply.

I do not believe you made a sufficient effort to understand. I have no interest in explaining this, I was providing an explanation as a service to you. Until you demonstrate that you actually did make an effort, I will not continue elaborating.

I stared at your example post and thought about it for 10 minutes before I replied. I'm sorry.

>Shouldn't your seed be different in order to get different values?
You incorrectly assume that state is immutable here. Seed value changes with each call, even if it stays in the same variable in your program, in same place in memory.

>Okay, so state is a collection of otherwise logically disjointed data?
No, this is not a definition of state. This only accounts for a small part of what may be required for an argument to function to be classified as a state. I wrote the word in capital letters for you, multiple times, and you still pretend it's not there.

Its shit op dont doit

I'm not ignoring it, it just doesn't make sense to me. Obviously you're going to pass the argument you need around to the functions that ask for it because you want them working with the same thing. You're always going to pass what the programmer INTENDS to the functions, you wouldn't pass an incorrect type or an irrelevant variable.
Is it a state variable if you are intended to pass the same variable around to multiple functions?
>You incorrectly assume that state is immutable here
I just misread what you said "You are intended to pass seed, same data in memory, to multiple calls."

>Is it a state variable if you are intended to pass the same variable around to multiple functions?
In very broad terms, yes.

It's good.
But functional programming languages are unpopular and limited to rather basic tasks.
You'll find that functional programming languages favor 'proper' functional programming and often makes more expedient solutions cumbersome. For better or worse.

...

How about in a little bit more specific terms?

Because arguing for compromise in a situation where none is needed is pointless and stupid.

FP is hard to do.

If you want to get shit done with it, you generally do a hybrid style like what most do when they use Scala.

State is a bunch of data grouped together, designed to be used in multiple calls to one or more functions.

NoNutNovember

You must be a moroon to respond to macro images.

Okay, it makes more sense now that I've reasoned it out. Thank you.

Do you think user here didn't intend to say what the image pointed out?
The way I interpret macro images is just that the person find themselves too stupid to constructively participate. But that doesn't mean we should just ignore the morons.

Also it's not like user put less effort into this post than someone writing the same thing. Takes way less effort to write than go look for the image.

#Mathematica
en.m.wikipedia.org/wiki/Cargo_cult_programming

Just because I 'clicked' Submit, doesn't mean I'm a fucking retard!

"Don't get set into one form, adapt it and build your own, and let it grow, be like water."

Eastern Philosophers vs Western Philosophers. Epic Rap Battles of ...m.youtube.com/watch?v=0N_RO-jL-90

Mathematics is an isolation filter!+1

I'm so glad I learned functional programming before OOP.
Going from functional -> OOP is just adding extra rules, and its a natural progression
Going from OOP -> functional is like ripping out the scaffold rules about coding that you took for granted the whole time you were learning and trying to imagine a world that isn't confined to those rules.

Anybody who starts off in Java is getting cucked.

You'll learn that OOP is not awful and almost unreplaceable when you'll have to work on a large shared codebase with coworkers, if you'll ever get a job instead of spouting what you read on Sup Forums.
It's especially useful at getting readable, pseudo-maintainable code out of retard coworkers that somehow managed to find themselves in the fiels.
OOP is not for good programmers, it's to keep in chek bad programmers and limit how bad their code can get and how unreadable it is when you have to put your hands on it.

#commenting(s)'

西蒙。添加他們的日本buttsluts。

Jeopardy: What is SNR?

Japanese!

The main problem with OOP is how it favors structuring data in a fundamentally flawed memory layout that causes tons of cache missed lookups. This makes most software run far slower than it should, becoming far worse with each additional level of inheritance and abstraction.

Also, traditional imperative approaches that are commonly associated with OOP favor non-parallelizable code and make compile-time optimizations require far more engineering.

Not saying that OOP is worse. It just makes it far easier to write bad code.

U=Weeaboo!

NGA (Neon Genesis Evangelion.)

Shinji (te)!

>tfw Sup Forums shitposting is deep in my consciousness

Yarvin, is that you?
Please explain Urbit to me

>imitating OOP
No one's trying to imitate inheritance, getters/setters or abstract builder factories. Everything that changes state in a struct isn't OOP.

...