Does object oriented programming even make sense in "normal" programs? It obviously makes sense in games and such...

It makes sense when you have more than just a couple of developers working on it, especially when you have dozens or more. It's easier to read, it adheres to certain standards that are easier to enforce, and someone else can usually read it and not have to decipher some Indian bullshit voodoo for 5 hours.

wiki.c2.com/?BenefitsOfOo
wiki.c2.com/?ArgumentsAgainstOop

What is wrong with type inference? Assuming you're talking about var, auto, etc.

>It obviously makes sense in games and such, where each entity has it's own object

Don't use OOP op, it's awful and hurts your head. You'll thank me in four years.

it's bad when it's overdone like in rust

valid rust:
fn main() {
// type vec?
let mut vec = Vec::new();
let elem = 5u8;
// vec's actual type is decided here
vec.push(elem); // vec
}

That's actually pretty neat. I'm going to check out Rust now, thanks user.

>efficiently
HA
Spotted the bait right there
> Anonymous 06/03/18(Sun)22:55:38 No.66197388▶

(OP)
OOP and type inference are the two biggest mistakes of programming languages.
These two have literally no reasons to exist.
Pure imperative or functionnal are extremely powerful and you can absolutly everything, efficiently.
I'm still open to example where OOP REALLY isbetter than pure anything
Pure is always expensive.

What exactly is OOP and what's wrong with it?

Then you're not doing object-oriented programming. OP isn't talking about C++, he's talking about OOP.

Everything is wrong with it.

Why is that?

OOP was a great idea when there was no internet and all programs were installed directly on your computer and so the data in those programs never changed and so making functions part of the data type made sense then. It doesnt make sense now. Class-based OOP relies too much on inheritance, inheritance is almost never the right abstraction unless you are dealing with monlithic static data that never changes.

Stop feeding the trolls, you fuckwit.

>OOP was a great idea when there was no internet and all programs were installed directly on your computer and so the data in those programs never changed and so making functions part of the data type made sense then. It doesnt make sense now.
Are you saying contant functions are invalid because internet is more accessible?
>inheritance is almost never the right abstraction
Why can't inheritance describe an `is-a` relation abstraction properly?

A simple example is (since everything is an object, and data and functionality are coupled): What handles the post you just made conceptually and how should you group that up?

Was it the website? The Operating system? The internet?
You run circles around design problems and implementations fall apart.

>Are you saying contant functions are invalid because internet is more accessible?
no, I never said anything like that

>Why can't inheritance describe an `is-a` relation abstraction properly?
I dont know, you tell me, I never said anything about 'is-a' relationships

That looks like a pretty arbitrary issue to me, the fact that you can name a group of entities (such as operating system, website etc) says that you would be able to classify them too. Furthermore you do not have to classify the primitives.

`is-a`relation is a data abstraction and you claimed inheritance can never be the right abstraction.

this is not functional syntax, retard.

>`is-a`relation is a data abstraction and you claimed inheritance can never be the right abstraction.
yes, I claimed inheritance is almost never the right abstraction, I didnt say anything about 'is-a' relationships. If you care to make some kind of connection, go right ahead, but Im not going to waste time responding to points that I never brought up

holy shit you're retarded

don't speak if you don't know what you're talking about

>I didnt say anything about 'is-a' relationships
`is-a` relationship is an abstraction, I said this already.

>It obviously makes sense in games and such, where each entity has it's own object.
It really isn't, it is just more human friendly, give the complexity of programming this things, it saves programmer hours.
Any game would run much better if it was properly programmed without OOP.

>`is-a` relationship is an abstraction, I said this already.
no, its a description of an abstraction, youre really a dumb fuck, if you dont have anything serious to say next post except goal post moving then Im going to stop responding to you

>Calls other people retard.
>Is a retard

What did he mean by this?

But can you classify their functionality?
For example, OP was talking about game objects.
What if we have a bullet class. Does the bullet fire itself? Is it a collection in a Gun class? Does it have any relation to the player? How will it know about the number of bullets already in the world? Does the gun fire the bullet and keep track of it? Should we even have a bullet class? Does it need to inherit from anything?

That sort of 'world modelling' doesn't work well in circuitry.

>its a description of an abstraction,
`is-a` is a description a relation
relation is an abstraction

Are you just pretending to be retarded or are you just being yourself? Why do you keep asking the same question?

>bullet class
Seems nice.
>bullet fire itself
these look like obvious questions.

A player contains a container of guns
guns contain chamber
chamber contains container of magazine
magazine has a container of bullets
Guns trigger a magazine to lose a bullet.
>How will it know about the number of bullets already in the world?
Not counted. Not an OOP question. And the answer won't change no matter what paradigm you use.
When a bullet fired, it will notify HUD or it's gun object
>does it need to inherit
Sure, it should inherit from projectiles, then again, detail of implementation is upto you

>`is-a` is a description a relation
>relation is an abstraction
>Are you just pretending to be retarded or are you just being yourself? Why do you keep asking the same question?
...

When I learned it, it heavily simplified my programs.

Fine. That's all okay so far.
What about data hiding/encapsulation? Should the bullet's member variables be private or public? Does it need to implement any inherited methods?

What about enemy bullets? Does the Enemy class inherit from the same base class that Player does?

The problem is that there is no answer. It;s all too abstract to tell.

> It obviously makes sense in games and such, where each entity has it's own object.
Nah not really. Haven't you heard of game devs lord and saviour? ECS? That's basically just old style C made shit.

usually, in C++, you don't have public variables.You use getters and setters instead.

>enemy bullets
still bullets. Thanks to OOP, you have to rewrite only a fraction of the code (I mean specialize) in your game

>Does the Enemy class inherit from the same base class that Player does?
Yes absolutely, both of them are actors

The inheritance hierarchy does make it complex but you have a more robust, fault proof and reusable code base in return. I'd say it's only fair.

>usually, in C++, you don't have public variables.You use getters and setters instead.
That's a stupid way of thinking. Only encapsulate if it's needed to be.

>Yes absolutely, both of them are actors
OOP prefers composition, would prefer them to have actors IMO.

Getters and setters sound alright.
Wait, except in this case they're hidden in the source code. Now the member variables are private, I can't access them directly.
But how do I know what is actually happening in the get/set functions when I just want a simple read or increment?

Your next problem is the heap and creating classes on it, not to mention abstract/virtual base classes and their performance problems.

I'll say it again: OOP isn't good for anything, people just think it's orderly and organised. It hurts everything. I say this out of love.

imo inheritance turns code into complete spaghetti

Object orientation is shit, but having good support for objects is a good thing. Learn the difference

>what is documentation mommy?

Something nobody reads or wants to maintain when they make an edit

That's why OOP says prefer composition over inheritance. But there are some places where inheritance is perfect.

something completely orthogonal to OOP vs other paradigms you giant fucking babby

I just saw this thread on the front page, can someone give me a quick rundown on functional programming?
>just finished a CE degree
>applied for 400+ jobs in software engineering
>all of them require knowledge in OOM
Am I feeding the trolls

I can't give you a quick rundown, but this is what put me down the path of autism. Jow Forums hates scala, but personally I think it's the GOAT language and I prefer the haskell fanfic scala to real haskell.

Attached: red book.jpg (318x399, 44K)

>quick rundown on functional programming
It is programming without "side effects". Note that "side effect" is not in the sense of something unintentional, but as in no mutable state. Want to edit something? Chain functions together that each act on a modified copy of some value.

Read a book on obj oriented design and study patterns. Then you'll see how they are used as factory components to make working software. The examples they give you in classes like pet becomes dog, cat, hamster are just examples. In real design objects are used for components more than the data being processed

Fuck private/protected variables. Fuck writing a function just to return their value.

this is accurate, but I would like to put emphasis on higher level abstractions that makes chaining functions together easier, i.e how you can get immutability without being hamstrung. That said, in lisp these concepts arent important, so what I'm talking about is really expressive types + FP, two concepts that are orthogonal but enhance each other.

Attached: spede.jpg (246x278, 8K)

I used to think that, but then I realized that if you can make it inline, there is zero overhead to doing that.

Why though? When you're not a basement dweller and get an actual job, you need to write systems that others are going to use. If you have an internal state variable that's predicated on a function call, you can't just expose it without breaking the system.

well there's nothing wrong with codegolfing as long as you're not writing real software

user, most games don't even do that. There's almost always some level of abstraction like an ECS
I will say that OOP makes some sense for high level architecture, and things like UI where you have a lot of variations on the same concept. You would essentially end up emulating OOP concepts in an imperative language which is far worse than using an actual OOP lang for the job.

If you have a bunch of useless get/set functions with no other logic in them you're absolutely fucking up OO. Even having private state isn't ideal, the less state the better, but if you must have internal state it needs consistent validation when being set, and should only be "got" in a consistent state.

Hi, I am retarded and don't understand OOP. When writing PHP code I use a lot of $this->function();[\code] calls.
But I just want to call my damn function.
$rowArrays = array_map('Scraper::splitRow',$scrapedData);

public static function splitRow($row) {
return array_map('trim',preg_split("/[\n]+/",$row));
}
[\code]

Why the hell won't this work dammit.

>php

Attached: KDZEWFoCkuiGTi-k5c6Q3bLlyaenrGaEmo1YuljM_Fc.jpg (229x221, 10K)

A mans gotta eat user. I am of the opinion that php is slightly less retarded than javascript.
I still don't understand the concept of an ArrayObject, real pieces of shit they are.

They're equally retarded, but js is mandatory unless you transpile. Anyways, fix your code tags and I can look at it.

I don't know how to code tag user, here's hoping. I am in the Scraper class and I want to call the splitRow function. Wondering why every damn function call needs a $this-> prefix and whether to use $this in my array_map call.
public function toArray($scrapedData) {
$rowArrays = array_map('Scraper::splitRow',$scrapedData);
// Do some stuff with $rowArrays
}

public static function splitRow($row) {
return array_map('trim',preg_split("/[\n]+/",$row));
}

OO is usually pretty shitty. Sometimes it's a good fit for the problem, but usually functional programming has less impedance mismatch. Most programming problems are best distilled to functional operations on data. data in, data out.

Single dispatch OOP is nigger tier. Multiple dispatch is the only OO system worth using.

Prove me wrong.

wiki.c2.com/?MultipleDispatch

Depends how you define OOP. Common sense encapsulation and interfaces containing pure virtual functions? Sure. Full retard over abstraction, ridiculous inheritance heirarchies and use of design patterns over lambdas? Fuck right off.

Quick update on my problem here... It's really late and I'm tired and I thought that $scrapedData was an array, but it's not. So the function call was being called all along, but returning NULL because php and me are both retarded.

hah, I tried to decipher your problem, but I had no idea what you were asking.

Anime website.

>muh machine abstraction is better than yours

They all have at least one pro and one con, just like oop.
Arguing which is better is pointless.

>class based OOP in languages with dynamic typing

Why does this even exist?

Attached: 1473904892658.jpg (1106x1012, 362K)

>It obviously makes sense in games and such, where each entity has it's own object.
One of the few cases where it can be useful. But its not really needed.

OOP is great. Inheritance is almost always bad, but sometimes ok. Composition is usually the better choice. Getters/setters are fine too but mostly overused.
C++ is a great language. It's a very good middle ground between low and high level abstractions.

>C++ is a great language.
No it isn't. It's just OK, but not actually all that fast. C# is faster.

I havent really seen a single solid argument for dependency injection that makes sense with the exception of really expensive resources like a database connection. It looks like just another level of inderection that we could do away with by just passing parameters like normal function.

>I dont understand what OOP is and I dont have any real criticisms of it but it sucks
Every Object oriented thread on Jow Forums ever

>C# is faster
You can't be serious, C++ is considerably faster overall if we're talking about performance. C++ is usually pretty much on par with C in terms of performance unless you mess up.