Same shit as goto, some bad examples being cringeworthly bad making the autists think the thing itself is bad, when the thing when well use is actually benefical.
lasagna sucks. it's a big mess of everything just squashed together, it's bloated and bad for your health, and doesn't even taste that good.
2 years ago
Anonymous
lrn2cook
Functions are abused way more.
I will now proceed to hate FP solely based on this single fact.
referential transparency helps a lot with magic function bullshit. you need to be apt at type tetris though and that sort of coding style will get you yelled at at most offices
Your picture does not include C#, so it's OOP implementation should be good for sure!
But for real, OOP capabilities make languages applicable for wider range of tasks with consequent influx of popularity. And wide adoption makes it default choice for your everyday moron. If pajeet programming courses will start Haskell classes, I have no doubt, somebody will be creating threads "Functional kills the industry!" daily. I just can't understand, why would somebody choose instrument of similar quality with less capabilities over one with more capabilities.
There's many places you can put the goalposts for OOP, the goalposts he talks about only exist in his own head
objects (data bundled with functions and operate on it) are good
Inheritance is good and even useful when you understand how to use it
C# OOP is decent, C++ OOP is ok
2 years ago
Anonymous
These extra "capabilities" are pure bullshit, OOP is a cargo cult.
Comparing it to FP is moronic because FP is as old as OOP.
2 years ago
Anonymous
>Inheritance is good
in the trash you go
2 years ago
Anonymous
you can't dispute that, because you're a cargo cult brainlet
2 years ago
Anonymous
In the mind of a schizo, everyone but him is insane.
OOP can be done well but it's a path of greater resistance than doing it badly.
2 years ago
Anonymous
doing OOP well isn't hard
2 years ago
Anonymous
don't talk to me about cargo cult bullshit when you're so attached to a paradigm that was advocated only to sell consulting and books
I wanted to like them, because I, too, do not like OOP. But he fails to articulate a coherent alternative. His follow-up videos use toy examples and in some cases his code winds up being worse.
Think of the Sandi Metz one where he uses a bunch of parallel switch statements LOL. That can be fine, but can also be worse, and he doesn't get into the nuances of when to choose which. (I think this is actually a huge problem with software engineering discussions in general. There are no silver bullets. Some techniques are appropriate in some circumstances and other techniques are better in other circumstances, but no one ever talks about that, it's always just: SOLID, SOLID, SOLID!!! or OOP IS FOR STUPID PEOPLE!)
I really was hoping he'd show us how his method is superior by rewriting a large codebase that had all the typical OOP stuff:
- multiple wide but shallow inheritance hierarchies
- multiple of cross-cutting concerns like logging, metrics, etc...
- factories
- template methods
- "helper" and/or "manager" classes
- use of a DI framework
- code that receives some input (like a UI event or a network request) and then does subsequent I/O (like a database call or an outgoing network request) that differs depending on the input. (This is the kind of common example that is missing from almost every discussion of software engineering techniques and thus renders almost all of them so trivial as to be meaningless.)
Because it works. If you have the patience to watch or at least skip through YT lectures on functional programming, you'll find that its just pedants b***hing about OOP while saying almost nothing about FP.
>If you have the patience to watch or at least skip through YT lectures on functional programming, you'll find that its just pedants b***hing about OOP while saying almost nothing about FP.
that's because unfortunately most of the gays covering FP on youtube are pseuds trying to show how smart and superior they are by rejecting the popular OOP.
if you really want to see what's up with FP read a book or two on haskell and/or lisp. It's actually very comfy once you get used to thinking in functional terms
it's faster to write and test/debug, which nowadays tends to matter more than the program itself being faster >inb4 strawman cherrypick "moron, performance matters!!! why are you saying it doesn't!!??"
yes, obviously in many cases performance is important and fp makes no sense, especially lower level stuff, but in a world where webshit is taking over and computers are fast and users dont give a crap, developer productivity and writing reliable stuff is what's becoming more important, which fp facilitates.
>Which is what matters
imagine writing this with a straight face, on a bloated browser running a shitton of js bloat on top of a bloated monolithic os
every ounce of hw performance improvement in the past 2 decades was successfully nullified by codemonkies not giving a flying frick about performance
?t=44
Timestamped. Moore's law is dead unless we take advantage of parallelism.
Functional programming can map pretty well to distributed, parallel routines. I'm not saying imperative can't be faster, most of the time it will. However, with what I mentioned above, there is a lot of speed to be gained with very little effort in functional programming. Especially when refactoring existing code. Which big companies value a lot.
I watched the vdieo awhile back. my main evaluation of it is that the things he were talking about were weaknesses of OOP, but they weren't think that automatically made OOP bad.
I think the biggest issue with OOP is how easily it can become a hopeless tangle of inheritance, abstract interfaces, mixins, and every other design pattern that popped into someone's head. Some of the OOP heavy C++ code I work on for my job is basically impossible to modify. Smart pointers and templates everywhere. It's just too easy to get lost in the abstraction and completely lose sight of what you're actually trying to make the computer accomplish. I don't think it's inherently bad as a paradigm, but it needs way more discipline to stay sane than most people have.
inheritance does not even scratch the surface of OOP and I personally don't use it anyway so it's funny to see homosexuals always get hung up on this one issue that can be avoided altogether.
I guess chinkBlack personjews are mad that BASED users are realizing that: the Functional logical imperative methods are the only solutions to escape the matrix
ITT: Pajeets and OOP cultists seething about how their 14 million Abstract Data Factory Factory Consumer Managers are actually a good design pattern and best practice because their professor who learned Java in the 90s, during the OOP craze, said so.
OOP is the best way to group variables with associated functions which operate on those variables. Imagine having to do some homosexual shit like strlen(mystr) instead of mystr.length()
The prototype shit is basically a base object in which every object (including js primitive types) extends from. Same shit with Python. At its core it's OOP and it's use is multi-paradigm
>das not how hardware werks!!!!!
the quintessential dunning-kruger take
2 years ago
Anonymous
i'm beginning to doubt you're experienced enough to hold opinions on the topic
>FPschizos keep acting superior and pretend Haskell wasn't a colossal failure
If your system was even remotely superior to OOP, it would have taken over easily instead of being slowly integrated into OOP-first languages.
2 years ago
Anonymous
i haven't advocated fp and i don't like haskell
2 years ago
Anonymous
>slowly integrated into OOP-first languages
This tells you more about OOP devs than anything else.
>heh we're only beginning to do some of the stuff FP devs were doing decades ago! Take that chud!
2 years ago
Anonymous
>haskell is the only FP language
every time
next you'll call us ivory tower academics
What you have to understand is that autistic people generally lack creativity. They have very ridged patterns of thought, which is typically why you find them in less demanding fields like embedded. When it comes to OOP you're typically writing code that's going to be >Long lived >Extensible >Maintainable >Flexible
Which is why you so often see design patterns employed with OOP (but rarely with C or other imperative languages). To write good OO code you need to be creative, you need to look at a problem and start a design phase: >What does my domain model look like? >What's the best algorithm? >What design patterns let me loosely my domain model into the code?
You'll write some test implementations, maybe have some peer review. Finally you'll write your actual code. All these steps are things that are typically beyond the ability of your average autist. So when they write any OO code i quickly becomes an unmanageable, unusable mess.
I should probably add that your average developer is also pretty bad at this, but for different reasons. You average developer wants to "write code". But they typically don't want to "design software".
those are the shilling points in an ideal world, but then the reality is usually ths:
I think the biggest issue with OOP is how easily it can become a hopeless tangle of inheritance, abstract interfaces, mixins, and every other design pattern that popped into someone's head. Some of the OOP heavy C++ code I work on for my job is basically impossible to modify. Smart pointers and templates everywhere. It's just too easy to get lost in the abstraction and completely lose sight of what you're actually trying to make the computer accomplish. I don't think it's inherently bad as a paradigm, but it needs way more discipline to stay sane than most people have.
Poor use of inheritance and a frick tonne of hidden implementation leading to shitty performance because the developer doesn't know how his OOP framework works.
DOP (Data Oriented Programming) is better for performance and refactoring. It's why game devs chose DOP over OOP. Game devs are ahead of the curve when it come to programming. They tried the scripted language shit long before JavaScript and Python heads come into the scene and deemed it to be a complete mess. They did preliminary rounds and saw the mess that is JavaScript Frameworks and killed it in the industry before it grew up.
OOP is fine if the devs reduce inheritance and opt in to use well documented Interfaces instead. If Inheritance is essential keep the functionality of the parent class minimal and light.
They use DOP. DOP still uses OOP that's why it's hard to tell the difference. Only a moronic dev will opt-in to use OOP. He will have to rebuild his entire framework just to improve performance or end up writing everything everywhere as obsolete in the documents.
>DOP still uses OOP
You said they use "DOP over OOP". They aren't mutually exclusive. Games use OOP because OOP is great for modelling games. From the smallest game to the biggest most well architectured AAA game. Stop talking out your ass
2 years ago
Anonymous
>They aren't mutually exclusive
It's a paradigm homosexual. OOP still uses procedural programming. >Games use OOP because OOP is great for modelling games
Like I said, you're too moronic to tell the difference. Learn DOP and comeback. DOP and OOP are both great for modelling. Your point is moot. OOP is just the brainlet's version of modelling.
For underlying system DOP is used. Writing a particle system using pure OOP is a bad idea you're gonna run into performance problems quickly. This is why your V8 based browser is shit at rendering. The morons over at israelitegle decided to write their renderer in OOP. You won't be playing tripple A 3d games in your browser anytime soon even though it's just a fricking window.
>From the smallest game to the biggest most well architectured AAA game. Stop talking out your ass
They use DOP for heavy lifting and OOP and the turd stuff or prototyping. Sometimes they forget to remove the prototype shit because of time constraints.
2 years ago
Anonymous
You don't have a fricking clue what you're talking about
2 years ago
Anonymous
>I am a moron
exactly.
Like I said. Learn DOP. Learn OOP thoroughly to the point of knowing SOLID and Design Patterns. Learn what Programming Paradigms are then come back.
2 years ago
Anonymous
I "know" both of those things
I've been working on game engines for a very long time
I already told you, DOP and OOP are not mutually exclusive. The biggest, most performant games are OOP from top to bottom
You're repeating misinformation
2 years ago
Anonymous
>I already told you, DOP and OOP are not mutually exclusive
I never made this claim.
I said use DOP and use OOP with interfaces rather than inheritance. Keep Inheritance minimal.
That's what I said if you could read. I never hated on OOP. I simply spoke the truth and clarified by schizos have PTSD over OOP. It's because they never been taught OOP properly or were forces to rely on shitty OOP frameworks.
DOP and OOP work well for games. AM (Actor Model) and OOP work well for desktop class applications.
2 years ago
Anonymous
You said >DOP over OOP >DOP for heavy lifting and OOP and the turd stuff or prototyping
Both of these things are just false
You didn't say >use OOP with interfaces rather than inheritance
which is also not good advice, there's nothing inherently wrong with inheritance
2 years ago
Anonymous
>You said >DOP over OOP
What does this have to do with mutual exclusivity? They're a paradigm. OOP methods rely on procedure programming. Does that mean I should code only in procedural? Does that mean OOP and Procedural programming are mutually exclusive?
>DOP for heavy lifting and OOP and the turd stuff or prototyping >Both of these things are just false
You're a bedroom dwelling game engine dev. You're a brainlet who only does what he is told just because he is told to do so.
Unreal Engine 3&4 are OOP behemoths. That's why they're sluggish and slow. They're code bases are ancient and unmaintainable. They have the same rendering problem Chrome has.
Epic devs are now advocating DOP.
>use OOP with interfaces rather than inheritance >which is also not good advice, there's nothing inherently wrong with inheritance
Jesus Christ. Go download the Unreal Engine code base and try to add make a small change to the render and watch how quickly the problem cascades.
OOP has its weakness and the miss use of inheritance is a problem. Read up on design patterns and SOLID. There's a reason why they heavily relay on interfaces.
2 years ago
Anonymous
I've worked on several AAA engines
You don't know what you're talking about
You continue to talk about DOP as if it's mutually exclusive with OOP when it's not. OOP does not equal slow, at least not in C++
2 years ago
Anonymous
>I've worked on several AAA engines
As a code monkey? You barely know design patterns and you barely know what solid is. You legitimate advocated for Inheritance over Interfaces which is a 60IQ move. You're internet accreditations dont mean shit, if you cannot back them up with knowledge. You barely elaborated on you points.
>You continue to talk about DOP as if it's mutually exclusive with OOP when it's not
Again. Where do I say they're mutually exclusive?
2 years ago
Anonymous
I know what design patterns and SOLID are, not sure where you got that idea. But those things are mostly Java cope and not relevant to writing good C++ code
inheritance and interfaces are used for different things, you shouldn't use one over the other
>Where do I say they're mutually exclusive?
When you say "Use DOP for X and OOP for Y"
You use both at the same time. Your objects can be "data orientated"
2 years ago
Anonymous
>I know what design patterns and SOLID are, not sure where you got that idea. But those things are mostly Java cope and not relevant to writing good C++ code >inheritance and interfaces are used for different things, you shouldn't use one over the other
Anon. If you cannot use design patterns in C++ you're a moron. If you don't know what interfaces are, you're a moron. No fricking shit Interfaces and Inheritance are different.
Let me put this in a way you understand.
Inheritance - Getting a driver's license for every make and taking extra classes for every model
Interfaces - Owning 1 driver's licenses and driving any car you want no matter the model.
2 years ago
Anonymous
You don't need to try and educate me, I know what all these things are, like I said, I've been doing it for a long time
what you think of as "design patterns" from the GoF book are Java cope. You should not be doing this shit in C++, at least if you want to be a good programmer
2 years ago
Anonymous
Anon. Design patterns are not a Java Thing. Design Patterns are an OOP thing. When using OOP you use design patterns. Problems with OOP are OOP problems. They don't disappear no matter what language you use.
2 years ago
Anonymous
Design patterns, as in literal design patterns, are everywhere. "Design patterns" in the sense of OOP design patterns as defined by the GoF book, the kind you're talking about, are for Java's specific OOP implementation. Java's OOP implementation is very inexpressive. In better OOP systems, you don't need to use most of these patterns, there's better options. C++ has a shit OOP implementation, but it has a whole lot of other features too, which make most of the patterns in that book an inferior choice
2 years ago
Anonymous
You're essentially right, but slightly off. OOP design patterns are ways to get around some OOP languages' lack of first-class & higher-order functions in the 90s. So in the 90s that was Java and C++, rather than only Java.
2 years ago
Anonymous
C++ had first-class functions in the 90s though
2 years ago
Anonymous
I should have said closures, to be honest.
2 years ago
Anonymous
Even just having first-class functions makes many design patterns obsolete. That link above, most of those apply to C++ aswell
2 years ago
Anonymous
>as defined by the GoF book, the kind you're talking about, are for Java's specific OOP implementation
But GoF was written in C++ and smalltalk.
2 years ago
Anonymous
Design patterns, as in literal design patterns, are everywhere. "Design patterns" in the sense of OOP design patterns as defined by the GoF book, the kind you're talking about, are for Java's specific OOP implementation. Java's OOP implementation is very inexpressive. In better OOP systems, you don't need to use most of these patterns, there's better options. C++ has a shit OOP implementation, but it has a whole lot of other features too, which make most of the patterns in that book an inferior choice
Also GoF was published a year before the initial release of Java. You're talking out of your ass.
2 years ago
Anonymous
I assumed it was written for Java, for the reasons I stated, these pattterns are sub-optimal in C++
Programming according to that book in C++ would just be moronic
2 years ago
Anonymous
>I assumed it was written for Java
So you are talking out your ass. I could tell from the numerous moronic things you've said, but this just confirms it.
2 years ago
Anonymous
I've never read that book, but I know the design patterns it recommends
2 years ago
Anonymous
You're not helping yourself.
2 years ago
Anonymous
Despite making a mistake on the detail here my point remains the same. Your point is completely wrong, it's based off misunderstandings. The idea that games don't use OOP because it's incompatible with performance and "data orientation" is wrong. It's a lie that's somehow spreading through the internet amongst people who don't actually program games
2 years ago
Anonymous
>They don't disappear no matter what language you use.
technically not, but i'd argue that different languages' communities have different levels of cargo cult mentality
best example is how languages like clojure are very culturally distinct from java, even though they run on the JVM and have full java interop
2 years ago
Anonymous
>GoF book
Was written for C++.
https://en.m.wikipedia.org/wiki/Design_Patterns >Design Patterns: Elements of Reusable Object-Oriented Software (1994) >1994
>The book includes examples in C++ and Smalltalk.
>Criticism has been directed at the concept of software design patterns generally, and at Design Patterns specifically. A primary criticism of Design Patterns is that its patterns are simply workarounds for missing features in C++, replacing elegant abstract features with lengthy concrete patterns, essentially becoming a "human compiler"
https://en.m.wikipedia.org/wiki/Java_(programming_language) >First appeared: May 23, 1995
OH NO NO.
And what's this?
2 years ago
Anonymous
>Peter Norvig demonstrates that 16 out of the 23 patterns in Design Patterns are simplified or eliminated by language features in Lisp or Dylan.
https://www.norvig.com/design-patterns/
2 years ago
Anonymous
>16 out of 23
Ummm you didn't prove him wrong, you just re-enforced his point. Call me when you have 23 out of 23.
2 years ago
Anonymous
>16 of 23 holy commandments of OOP are just everyday language features in FP >Ummm you didn't prove him wrong
OOP brainrot ladies and gents
2 years ago
Anonymous
That's news to me, because many C++ features make the shit in that book obsolete
2 years ago
Anonymous
oh my god reading this gave me ptsd.
Let's think about classes in an easier way.
Picture a class called Animal.
Then you can have a class called cat which has a meow method.
And you can also have a class called Dog which has a bark method.
And these are just sub classes of the animal class! Isn't this great? It's just like real life!
2 years ago
Anonymous
I propose a new rule for discussions of object-oriented programming:
> **Anyone who brings up examples of Dog, Bike, Car, Person, > or other real-world objects, unless they are talking about writing a > clone of The Sims or something, is immediately shot**.
I feel that this new policy will improve the quality of the discourse
enormously.
2 years ago
Anonymous
Now let's say Animal is an Abstract class with a base methods specific to that animals. You have created Class for every Animal in the world.
Now you also have a Robot Abstract class with base methods which every robot in existence inherits from.
Now you want to make a Robo-Dog. Which class does Robo-dog inherent from? The Animal or Robot class?
If Robo-Dog inherents the Robot class are you gonna copy and paste the Animal class's base implementation? What if you forget to copy 1 method?
You see the problem here?
Now let's say you have a container/list/collection and you return read only methods. How will you do that with inheritance?
2 years ago
Anonymous
>design patterns and SOLID
All cope to emulate what FP can do out of the box. FP doesn't even have design patterns
2 years ago
Anonymous
>FP doesn't even have design patterns
Everything has design patterns
Monads are a FP design pattern
OOP is make-work. To the OOPmong, concise problem-solving is a bad thing. The OOPmong can't help but write methods that do nothing but parcel up data and pass it along to another method, which in turn parcels that up and passes it to another method, ad infinitum. Often, whole objects or hierarchies of objects are invented that do nothing other than pass data along to some other useless object.
get with the times; the dominant "programming model" of the enterprise is a tower of webshit microservices
also, most enterprise software is shit, so what is your point?
>OOD and DOD are mutually exclusive
They aren't though, that's the point I was trying to convey. You can have objects and you can have control over their layout in memory, which is what every game that cares about performance actually does
Ok maybe I should have clarified: they're approaches to software design whose main point of focus are [...].
You either mainly care about having interacting objects or mainly care about data access patterns.
But you can't have two #1 priorities. And OOD usually results in thinking of individual logical entities instead of batches of them, which most likely means that feeding the program a lot of data will reveal inefficient cache usage. But I don't know if it can be proven that OOD always forces this.
2 years ago
Anonymous
All programming is a balancing of multiple concerns. In C++, you have control over your memory layout. So you can have objects in an array, so long as they have a known size at compile time. So if you have a particle system, you have an array of particle objects, and these objects have a typical OOP interface, while being completely "data oriented". This is normal
Runtime polymorphism via inheritance means you don't know the size at compile time, but OOP does not necessitate you do this, you pick and choose where you want to use virtual functions
2 years ago
Anonymous
>But I don't know if it can be proven that OOD always forces this
Since they never had to deal with big projects they can't see why the object paradigm is useful.
people complaining about OOP are the same people claiming that writing code on a terminal is better than a IDE. They only deal with a couple of line of code can call themselves software developers.
Since they never had to deal with big projects they can't see why the object paradigm is useful.
people complaining about OOP are the same people claiming that writing code on a terminal is better than a IDE. They only deal with a couple of line of code can call themselves software developers.
OOP has some part to play in big projects becoming big in the first place. protip: a large codebase is not actually a goal.
Linkrel is peak OOP performance. what an absolute unit https://android.googlesource.com/platform/frameworks/base/+/a175a5b/core/java/android/view/View.java
>good luck doing the thing everyone agreed was a terrible idea and is moving away from
not him but what did everyone agree was a terrible idea, and what is everyone moving to instead? last time i checked we all still use guis tbh
but java and c++ are the ones used everywhere, i love lisp but who actually uses smalltalk and clos nowadays? your post reads like "communism works but it's never been done properly!!"
When it comes to saying that OOP bad, I vastly prefer this lecture here. It does not spend its whole time deconstructing OOP and leaving the audience with nothing, instead it explains to the audience the virtues of functional architecture. And it leaves the audience to make the comparisons in their head between OOP and functional. No flame war BS, just learning.
very nice, just finished watching the whole thing
tl;dw: functional is nice because you can easily write maintainable, testable code using the language as it was meant to be used, whereas oop makes it easy to have a nice day in the foot with bad design patterns
Because they get filtered by usefulness
Same shit as goto, some bad examples being cringeworthly bad making the autists think the thing itself is bad, when the thing when well use is actually benefical.
goto is useless
>inb4 muh durr device
except goto is viewed as the mark of the beast, but i have never seen it misused while OOP is the standard, but constantly results in lasagna code
lasagna code is a good thing moron. lasagnas are structured, layered, and most of all delicious.
spaghetti is a tangled mess with shitty meaballs mixed in. fricking moron
lasagna sucks. it's a big mess of everything just squashed together, it's bloated and bad for your health, and doesn't even taste that good.
lrn2cook
referential transparency helps a lot with magic function bullshit. you need to be apt at type tetris though and that sort of coding style will get you yelled at at most offices
>lasagnagays seething
pathetic
that Brian Will rant is actually pretty good, his points are valid.
None of his points are valid if you have basic idea of programming.
>hehe his points are INVALID because i'm LE BASED PROGRAMMER.
Nice argumentation.
For some reason youtube keeps recommending it when i watch software engineering related stuff.
They aren't
He misrepresents OOP and argues against some rules he made up in his head
The goalposts are always moving.
Your picture does not include C#, so it's OOP implementation should be good for sure!
But for real, OOP capabilities make languages applicable for wider range of tasks with consequent influx of popularity. And wide adoption makes it default choice for your everyday moron. If pajeet programming courses will start Haskell classes, I have no doubt, somebody will be creating threads "Functional kills the industry!" daily. I just can't understand, why would somebody choose instrument of similar quality with less capabilities over one with more capabilities.
There's many places you can put the goalposts for OOP, the goalposts he talks about only exist in his own head
objects (data bundled with functions and operate on it) are good
Inheritance is good and even useful when you understand how to use it
C# OOP is decent, C++ OOP is ok
These extra "capabilities" are pure bullshit, OOP is a cargo cult.
Comparing it to FP is moronic because FP is as old as OOP.
>Inheritance is good
in the trash you go
you can't dispute that, because you're a cargo cult brainlet
In the mind of a schizo, everyone but him is insane.
OOP can be done well but it's a path of greater resistance than doing it badly.
doing OOP well isn't hard
don't talk to me about cargo cult bullshit when you're so attached to a paradigm that was advocated only to sell consulting and books
stop projecting
I wanted to like them, because I, too, do not like OOP. But he fails to articulate a coherent alternative. His follow-up videos use toy examples and in some cases his code winds up being worse.
Think of the Sandi Metz one where he uses a bunch of parallel switch statements LOL. That can be fine, but can also be worse, and he doesn't get into the nuances of when to choose which. (I think this is actually a huge problem with software engineering discussions in general. There are no silver bullets. Some techniques are appropriate in some circumstances and other techniques are better in other circumstances, but no one ever talks about that, it's always just: SOLID, SOLID, SOLID!!! or OOP IS FOR STUPID PEOPLE!)
I really was hoping he'd show us how his method is superior by rewriting a large codebase that had all the typical OOP stuff:
- multiple wide but shallow inheritance hierarchies
- multiple of cross-cutting concerns like logging, metrics, etc...
- factories
- template methods
- "helper" and/or "manager" classes
- use of a DI framework
- code that receives some input (like a UI event or a network request) and then does subsequent I/O (like a database call or an outgoing network request) that differs depending on the input. (This is the kind of common example that is missing from almost every discussion of software engineering techniques and thus renders almost all of them so trivial as to be meaningless.)
>parallel switch statements LOL
are you whining about seeing code that actually does something again?
>java
>overused
>low productivity compared to functional
>low productivity and bad performance compared to imperative
Because it works. If you have the patience to watch or at least skip through YT lectures on functional programming, you'll find that its just pedants b***hing about OOP while saying almost nothing about FP.
none of the vids in the image promote functional programming
Well none of those, but I'm just sayin.
>If you have the patience to watch or at least skip through YT lectures on functional programming, you'll find that its just pedants b***hing about OOP while saying almost nothing about FP.
that's because unfortunately most of the gays covering FP on youtube are pseuds trying to show how smart and superior they are by rejecting the popular OOP.
if you really want to see what's up with FP read a book or two on haskell and/or lisp. It's actually very comfy once you get used to thinking in functional terms
Real chads use whatever works best.
I don't know why brainlets think it's ALWAYS oop or ALWAYS functional
modern superscalars probably
a tasteful mix of imperative and functional is superior for almost every conceivable problem
functional programmers are nostalgia homosexuals who wish for simpler days.
Filtered by monads
theres not a single example of functional programming being faster.
Which is what matters.
it's faster to write and test/debug, which nowadays tends to matter more than the program itself being faster
>inb4 strawman cherrypick "moron, performance matters!!! why are you saying it doesn't!!??"
yes, obviously in many cases performance is important and fp makes no sense, especially lower level stuff, but in a world where webshit is taking over and computers are fast and users dont give a crap, developer productivity and writing reliable stuff is what's becoming more important, which fp facilitates.
>Which is what matters
imagine writing this with a straight face, on a bloated browser running a shitton of js bloat on top of a bloated monolithic os
every ounce of hw performance improvement in the past 2 decades was successfully nullified by codemonkies not giving a flying frick about performance
>OOP
>fast
don't google smalltalk benchmarks
?t=44
Timestamped. Moore's law is dead unless we take advantage of parallelism.
Functional programming can map pretty well to distributed, parallel routines. I'm not saying imperative can't be faster, most of the time it will. However, with what I mentioned above, there is a lot of speed to be gained with very little effort in functional programming. Especially when refactoring existing code. Which big companies value a lot.
There are examples of non-object-oriented programming being significantly faster.
?t=253
I imagine their only experience with OOP is ancient enterprise Java projects that have endless boilerplate code and excessive usage of inheritance.
I watched the vdieo awhile back. my main evaluation of it is that the things he were talking about were weaknesses of OOP, but they weren't think that automatically made OOP bad.
OOP is pOOP.
I think the biggest issue with OOP is how easily it can become a hopeless tangle of inheritance, abstract interfaces, mixins, and every other design pattern that popped into someone's head. Some of the OOP heavy C++ code I work on for my job is basically impossible to modify. Smart pointers and templates everywhere. It's just too easy to get lost in the abstraction and completely lose sight of what you're actually trying to make the computer accomplish. I don't think it's inherently bad as a paradigm, but it needs way more discipline to stay sane than most people have.
Subtyping is a spook
inheritance does not even scratch the surface of OOP and I personally don't use it anyway so it's funny to see homosexuals always get hung up on this one issue that can be avoided altogether.
I guess chinkBlack personjews are mad that BASED users are realizing that: the Functional logical imperative methods are the only solutions to escape the matrix
ITT: Pajeets and OOP cultists seething about how their 14 million Abstract Data Factory Factory Consumer Managers are actually a good design pattern and best practice because their professor who learned Java in the 90s, during the OOP craze, said so.
OOP is the best way to group variables with associated functions which operate on those variables. Imagine having to do some homosexual shit like strlen(mystr) instead of mystr.length()
Namespaces are better
standard::string::length(mystr)
See people say this and then turn around and jerk off to inversion of control.
Also JavaScript has this and isn’t OOP
The prototype shit is basically a base object in which every object (including js primitive types) extends from. Same shit with Python. At its core it's OOP and it's use is multi-paradigm
Using a class instead of namespaces
>symbol mangled thunk that does nothing but call the same 'homosexual shit'
mangled
totally irrelevant if you arent using a build system from the 1970s
why are you scared of functions?
>group variables with associated functions which operate on those variables
it is better not to encourage mutation
>mutation is bad
>please ignore how computers work
>please ignore how any IRL process works
FPhomosexualry belongs in the DSM.
>das not how hardware werks!!!!!
the quintessential dunning-kruger take
>FPschizos keep acting superior and pretend Haskell wasn't a colossal failure
If your system was even remotely superior to OOP, it would have taken over easily instead of being slowly integrated into OOP-first languages.
i haven't advocated fp and i don't like haskell
>slowly integrated into OOP-first languages
This tells you more about OOP devs than anything else.
>heh we're only beginning to do some of the stuff FP devs were doing decades ago! Take that chud!
>haskell is the only FP language
every time
next you'll call us ivory tower academics
i'm beginning to doubt you're experienced enough to hold opinions on the topic
Because it's often abused to write extremely bloated overengineered code that becomes a puzzle for everyone (including the compiler) to understand.
I'll bet you are one of those dumb Black folk who thinks guns are bad because some bad people use them to kill other people.
You sound like someone who denies the existence of a racial IQ gap because some exceptions exist.
Functions are abused way more.
I will now proceed to hate FP solely based on this single fact.
>Functions are abused way more.
what do you mean tbh?
It's popular, so by going against it they get to feel enlightened and superior to the plebs.
What you have to understand is that autistic people generally lack creativity. They have very ridged patterns of thought, which is typically why you find them in less demanding fields like embedded. When it comes to OOP you're typically writing code that's going to be
>Long lived
>Extensible
>Maintainable
>Flexible
Which is why you so often see design patterns employed with OOP (but rarely with C or other imperative languages). To write good OO code you need to be creative, you need to look at a problem and start a design phase:
>What does my domain model look like?
>What's the best algorithm?
>What design patterns let me loosely my domain model into the code?
You'll write some test implementations, maybe have some peer review. Finally you'll write your actual code. All these steps are things that are typically beyond the ability of your average autist. So when they write any OO code i quickly becomes an unmanageable, unusable mess.
I should probably add that your average developer is also pretty bad at this, but for different reasons. You average developer wants to "write code". But they typically don't want to "design software".
>>Long lived
those are the shilling points in an ideal world, but then the reality is usually ths:
Employer: how about your OOP skills?
Schizo: reeeeee i only know me functions did you know i can calulate nomad i mean monad
Employer: actually we just hired someone else
i can do oop just fine tbh, doesn't change the fact that it sucks ass
Riding a bike after just learned to ride without assisting wheels sucks ass too
watashi wa oopmaster tbh
Poor use of inheritance and a frick tonne of hidden implementation leading to shitty performance because the developer doesn't know how his OOP framework works.
DOP (Data Oriented Programming) is better for performance and refactoring. It's why game devs chose DOP over OOP. Game devs are ahead of the curve when it come to programming. They tried the scripted language shit long before JavaScript and Python heads come into the scene and deemed it to be a complete mess. They did preliminary rounds and saw the mess that is JavaScript Frameworks and killed it in the industry before it grew up.
OOP is fine if the devs reduce inheritance and opt in to use well documented Interfaces instead. If Inheritance is essential keep the functionality of the parent class minimal and light.
>It's why game devs chose DOP over OOP
They don't, 99% of games are OOP, especially the big ones where performance matters
They use DOP. DOP still uses OOP that's why it's hard to tell the difference. Only a moronic dev will opt-in to use OOP. He will have to rebuild his entire framework just to improve performance or end up writing everything everywhere as obsolete in the documents.
>DOP still uses OOP
You said they use "DOP over OOP". They aren't mutually exclusive. Games use OOP because OOP is great for modelling games. From the smallest game to the biggest most well architectured AAA game. Stop talking out your ass
>They aren't mutually exclusive
It's a paradigm homosexual. OOP still uses procedural programming.
>Games use OOP because OOP is great for modelling games
Like I said, you're too moronic to tell the difference. Learn DOP and comeback. DOP and OOP are both great for modelling. Your point is moot. OOP is just the brainlet's version of modelling.
For underlying system DOP is used. Writing a particle system using pure OOP is a bad idea you're gonna run into performance problems quickly. This is why your V8 based browser is shit at rendering. The morons over at israelitegle decided to write their renderer in OOP. You won't be playing tripple A 3d games in your browser anytime soon even though it's just a fricking window.
>From the smallest game to the biggest most well architectured AAA game. Stop talking out your ass
They use DOP for heavy lifting and OOP and the turd stuff or prototyping. Sometimes they forget to remove the prototype shit because of time constraints.
You don't have a fricking clue what you're talking about
>I am a moron
exactly.
Like I said. Learn DOP. Learn OOP thoroughly to the point of knowing SOLID and Design Patterns. Learn what Programming Paradigms are then come back.
I "know" both of those things
I've been working on game engines for a very long time
I already told you, DOP and OOP are not mutually exclusive. The biggest, most performant games are OOP from top to bottom
You're repeating misinformation
>I already told you, DOP and OOP are not mutually exclusive
I never made this claim.
I said use DOP and use OOP with interfaces rather than inheritance. Keep Inheritance minimal.
That's what I said if you could read. I never hated on OOP. I simply spoke the truth and clarified by schizos have PTSD over OOP. It's because they never been taught OOP properly or were forces to rely on shitty OOP frameworks.
DOP and OOP work well for games. AM (Actor Model) and OOP work well for desktop class applications.
You said
>DOP over OOP
>DOP for heavy lifting and OOP and the turd stuff or prototyping
Both of these things are just false
You didn't say
>use OOP with interfaces rather than inheritance
which is also not good advice, there's nothing inherently wrong with inheritance
>You said
>DOP over OOP
What does this have to do with mutual exclusivity? They're a paradigm. OOP methods rely on procedure programming. Does that mean I should code only in procedural? Does that mean OOP and Procedural programming are mutually exclusive?
>DOP for heavy lifting and OOP and the turd stuff or prototyping
>Both of these things are just false
You're a bedroom dwelling game engine dev. You're a brainlet who only does what he is told just because he is told to do so.
Unreal Engine 3&4 are OOP behemoths. That's why they're sluggish and slow. They're code bases are ancient and unmaintainable. They have the same rendering problem Chrome has.
Epic devs are now advocating DOP.
>use OOP with interfaces rather than inheritance
>which is also not good advice, there's nothing inherently wrong with inheritance
Jesus Christ. Go download the Unreal Engine code base and try to add make a small change to the render and watch how quickly the problem cascades.
OOP has its weakness and the miss use of inheritance is a problem. Read up on design patterns and SOLID. There's a reason why they heavily relay on interfaces.
I've worked on several AAA engines
You don't know what you're talking about
You continue to talk about DOP as if it's mutually exclusive with OOP when it's not. OOP does not equal slow, at least not in C++
>I've worked on several AAA engines
As a code monkey? You barely know design patterns and you barely know what solid is. You legitimate advocated for Inheritance over Interfaces which is a 60IQ move. You're internet accreditations dont mean shit, if you cannot back them up with knowledge. You barely elaborated on you points.
>You continue to talk about DOP as if it's mutually exclusive with OOP when it's not
Again. Where do I say they're mutually exclusive?
I know what design patterns and SOLID are, not sure where you got that idea. But those things are mostly Java cope and not relevant to writing good C++ code
inheritance and interfaces are used for different things, you shouldn't use one over the other
>Where do I say they're mutually exclusive?
When you say "Use DOP for X and OOP for Y"
You use both at the same time. Your objects can be "data orientated"
>I know what design patterns and SOLID are, not sure where you got that idea. But those things are mostly Java cope and not relevant to writing good C++ code
>inheritance and interfaces are used for different things, you shouldn't use one over the other
Anon. If you cannot use design patterns in C++ you're a moron. If you don't know what interfaces are, you're a moron. No fricking shit Interfaces and Inheritance are different.
Let me put this in a way you understand.
Inheritance - Getting a driver's license for every make and taking extra classes for every model
Interfaces - Owning 1 driver's licenses and driving any car you want no matter the model.
You don't need to try and educate me, I know what all these things are, like I said, I've been doing it for a long time
what you think of as "design patterns" from the GoF book are Java cope. You should not be doing this shit in C++, at least if you want to be a good programmer
Anon. Design patterns are not a Java Thing. Design Patterns are an OOP thing. When using OOP you use design patterns. Problems with OOP are OOP problems. They don't disappear no matter what language you use.
Design patterns, as in literal design patterns, are everywhere. "Design patterns" in the sense of OOP design patterns as defined by the GoF book, the kind you're talking about, are for Java's specific OOP implementation. Java's OOP implementation is very inexpressive. In better OOP systems, you don't need to use most of these patterns, there's better options. C++ has a shit OOP implementation, but it has a whole lot of other features too, which make most of the patterns in that book an inferior choice
You're essentially right, but slightly off. OOP design patterns are ways to get around some OOP languages' lack of first-class & higher-order functions in the 90s. So in the 90s that was Java and C++, rather than only Java.
C++ had first-class functions in the 90s though
I should have said closures, to be honest.
Even just having first-class functions makes many design patterns obsolete. That link above, most of those apply to C++ aswell
>as defined by the GoF book, the kind you're talking about, are for Java's specific OOP implementation
But GoF was written in C++ and smalltalk.
Also GoF was published a year before the initial release of Java. You're talking out of your ass.
I assumed it was written for Java, for the reasons I stated, these pattterns are sub-optimal in C++
Programming according to that book in C++ would just be moronic
>I assumed it was written for Java
So you are talking out your ass. I could tell from the numerous moronic things you've said, but this just confirms it.
I've never read that book, but I know the design patterns it recommends
You're not helping yourself.
Despite making a mistake on the detail here my point remains the same. Your point is completely wrong, it's based off misunderstandings. The idea that games don't use OOP because it's incompatible with performance and "data orientation" is wrong. It's a lie that's somehow spreading through the internet amongst people who don't actually program games
>They don't disappear no matter what language you use.
technically not, but i'd argue that different languages' communities have different levels of cargo cult mentality
best example is how languages like clojure are very culturally distinct from java, even though they run on the JVM and have full java interop
>GoF book
Was written for C++.
https://en.m.wikipedia.org/wiki/Design_Patterns
>Design Patterns: Elements of Reusable Object-Oriented Software (1994)
>1994
>The book includes examples in C++ and Smalltalk.
>Criticism has been directed at the concept of software design patterns generally, and at Design Patterns specifically. A primary criticism of Design Patterns is that its patterns are simply workarounds for missing features in C++, replacing elegant abstract features with lengthy concrete patterns, essentially becoming a "human compiler"
https://en.m.wikipedia.org/wiki/Java_(programming_language)
>First appeared: May 23, 1995
OH NO NO.
And what's this?
>Peter Norvig demonstrates that 16 out of the 23 patterns in Design Patterns are simplified or eliminated by language features in Lisp or Dylan.
https://www.norvig.com/design-patterns/
>16 out of 23
Ummm you didn't prove him wrong, you just re-enforced his point. Call me when you have 23 out of 23.
>16 of 23 holy commandments of OOP are just everyday language features in FP
>Ummm you didn't prove him wrong
OOP brainrot ladies and gents
That's news to me, because many C++ features make the shit in that book obsolete
oh my god reading this gave me ptsd.
Let's think about classes in an easier way.
Picture a class called Animal.
Then you can have a class called cat which has a meow method.
And you can also have a class called Dog which has a bark method.
And these are just sub classes of the animal class! Isn't this great? It's just like real life!
I propose a new rule for discussions of object-oriented programming:
> **Anyone who brings up examples of Dog, Bike, Car, Person,
> or other real-world objects, unless they are talking about writing a
> clone of The Sims or something, is immediately shot**.
I feel that this new policy will improve the quality of the discourse
enormously.
Now let's say Animal is an Abstract class with a base methods specific to that animals. You have created Class for every Animal in the world.
Now you also have a Robot Abstract class with base methods which every robot in existence inherits from.
Now you want to make a Robo-Dog. Which class does Robo-dog inherent from? The Animal or Robot class?
If Robo-Dog inherents the Robot class are you gonna copy and paste the Animal class's base implementation? What if you forget to copy 1 method?
You see the problem here?
Now let's say you have a container/list/collection and you return read only methods. How will you do that with inheritance?
>design patterns and SOLID
All cope to emulate what FP can do out of the box. FP doesn't even have design patterns
>FP doesn't even have design patterns
Everything has design patterns
Monads are a FP design pattern
what are some good books for object-orientated design?
DOP is the north Korean version of a programming paradigm OOP IS Black folkHIT
opp was the greatest invention after the air fryer and thermomix.
What triggers me about OOP is having maintained horrible OOP codebases.
If OOP was so great why didn't functional languages adopt OOP features? On the other hand the whole industry is adopting FP features.
>why didn't functional languages adopt OOP features
they did you moron
They actually did, they're just not popular in FP. OCaml is literally Caml + OO, but barely anyone even uses the OO anymore, lmao.
OOP is make-work. To the OOPmong, concise problem-solving is a bad thing. The OOPmong can't help but write methods that do nothing but parcel up data and pass it along to another method, which in turn parcels that up and passes it to another method, ad infinitum. Often, whole objects or hierarchies of objects are invented that do nothing other than pass data along to some other useless object.
Hipsters dismissing the dominant programming model for enterprise development.
>my boomer pajeet sir ceo <3 JAVA, we use it to maintain our 2 decade old legacy spaghetti, therefore oop good and you're a hipster
get with the times; the dominant "programming model" of the enterprise is a tower of webshit microservices
also, most enterprise software is shit, so what is your point?
>OOD and DOD are mutually exclusive
They aren't though, that's the point I was trying to convey. You can have objects and you can have control over their layout in memory, which is what every game that cares about performance actually does
Did you even read what I posted?
Ok maybe I should have clarified: they're approaches to software design whose main point of focus are [...].
You either mainly care about having interacting objects or mainly care about data access patterns.
You can care about both because they are not mutually exclusive
But you can't have two #1 priorities. And OOD usually results in thinking of individual logical entities instead of batches of them, which most likely means that feeding the program a lot of data will reveal inefficient cache usage. But I don't know if it can be proven that OOD always forces this.
All programming is a balancing of multiple concerns. In C++, you have control over your memory layout. So you can have objects in an array, so long as they have a known size at compile time. So if you have a particle system, you have an array of particle objects, and these objects have a typical OOP interface, while being completely "data oriented". This is normal
Runtime polymorphism via inheritance means you don't know the size at compile time, but OOP does not necessitate you do this, you pick and choose where you want to use virtual functions
>But I don't know if it can be proven that OOD always forces this
Scripters can't wrap their head around OOP.
Since they never had to deal with big projects they can't see why the object paradigm is useful.
people complaining about OOP are the same people claiming that writing code on a terminal is better than a IDE. They only deal with a couple of line of code can call themselves software developers.
good luck writing a GUI without OOP
moron
OOP has some part to play in big projects becoming big in the first place. protip: a large codebase is not actually a goal.
>moron
my point still holds
https://docs.microsoft.com/en-us/windows/win32/learnwin32/your-first-windows-program
i meant an actual useful gui with an actual toolkit like Qt or .NET, not your shit32
put your name on, bruce
LabVIEW uses Dataflow Programming.
stuck in the past
>good luck doing the thing everyone agreed was a terrible idea and is moving away from
Even webshitters are smarter than OOPtards
https://louis993546.medium.com/mental-models-of-jetpack-compose-3-inheritance-composition-and-why-they-matter-9a04dc874511
Linkrel is peak OOP performance. what an absolute unit https://android.googlesource.com/platform/frameworks/base/+/a175a5b/core/java/android/view/View.java
>good luck doing the thing everyone agreed was a terrible idea and is moving away from
not him but what did everyone agree was a terrible idea, and what is everyone moving to instead? last time i checked we all still use guis tbh
OOP guis
all the gui frameworks use oop though, what is everyone moving to?
Declarative
>all the gui frameworks use oop though
Wrong. https://developer.android.com/jetpack/compose
>OOP GUI
Man, what the frick are you smoking
Declarative and event driven is the way to go
>that android link
That's just really well documented code, all of us should learn from that
good morning
And what about SOLID?
https://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
Once again it's just OOPtards trying to ape FP in their own little moronic way
OOPtards can't wrap their heads around procedural programming.
OOP is procedural programming
so why can't you write anything of import?
what?
I said I am a moron!
>click link
>brwser tab hangs for a second
https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html
OK after reading this shitfling of a debate I'm siding with the OOP guy and declaring him the victor
Java isn't OOP. C++ isn't OOP. Only Smalltalk and CLOS have properly concieved OOP.
but java and c++ are the ones used everywhere, i love lisp but who actually uses smalltalk and clos nowadays? your post reads like "communism works but it's never been done properly!!"
When it comes to saying that OOP bad, I vastly prefer this lecture here. It does not spend its whole time deconstructing OOP and leaving the audience with nothing, instead it explains to the audience the virtues of functional architecture. And it leaves the audience to make the comparisons in their head between OOP and functional. No flame war BS, just learning.
very nice, just finished watching the whole thing
tl;dw: functional is nice because you can easily write maintainable, testable code using the language as it was meant to be used, whereas oop makes it easy to have a nice day in the foot with bad design patterns
spaghetti data patterns promoted as clean code.