>>25907
maybe anon meant explicit inheritance and polymorphism and all that OOP jazz? hell if I know
why does everyone hate OOP? I'm a codelet, only been studying Python for 2 mont…
LOUNGE · Back to threads · Report thread
Anonymous · reply · 2026-07-21 17:23:03
>>25886
Only brainlets hate it. The only "issue" are people who try to force it on everything, where other paradigms would be better.
Every good programmer is multi paradigm.
Only brainlets hate it. The only "issue" are people who try to force it on everything, where other paradigms would be better.
Every good programmer is multi paradigm.
Anonymous · reply · 2026-07-21 17:33:17
>>25935
No real code base uses OOP.
Everyone does procedural (now with a bit of functional) programming, except hastily and loosely wrapped in "objects", because most popular languages were created during the peak of OOP hype.
It's a historical artifact, nothing else, as computing is not immune to marketing, religion and ideology.
No real code base uses OOP.
Everyone does procedural (now with a bit of functional) programming, except hastily and loosely wrapped in "objects", because most popular languages were created during the peak of OOP hype.
It's a historical artifact, nothing else, as computing is not immune to marketing, religion and ideology.
Anonymous · reply · 2026-07-21 17:37:54
>>25886
I'm wouldn't call myself a good coder but I started to hate Java the more I work with it. Might be the projects I worked with but every single codebase was so utterly overdesigned with patterns and everything that following simply a method call would go through multiple classes with the function name and parameters always being the same just for two or three statements to be found at the end of the rabbit hole. It gets even worse if you want to debug and suddenly have wrappers and shit everywhere.
I'm wouldn't call myself a good coder but I started to hate Java the more I work with it. Might be the projects I worked with but every single codebase was so utterly overdesigned with patterns and everything that following simply a method call would go through multiple classes with the function name and parameters always being the same just for two or three statements to be found at the end of the rabbit hole. It gets even worse if you want to debug and suddenly have wrappers and shit everywhere.
Anonymous · reply · 2026-07-21 17:37:57
>>25938
you're definitely unemployed
you're definitely unemployed
Anonymous · reply · 2026-07-21 17:44:51
>>25924
>OOP does not solve the problems data-oriented design solves.
OOP can perfectly emulate data-oriented design by separating traits objects from instance representation objects. Actually a ho lot class based OOP warts are workaround for strong coupling of those two and static typing
>OOP does not solve the problems data-oriented design solves.
OOP can perfectly emulate data-oriented design by separating traits objects from instance representation objects. Actually a ho lot class based OOP warts are workaround for strong coupling of those two and static typing
Anonymous · reply · 2026-07-21 17:46:09
>>25924
>It's a whole paradigm using them in specific ways.
No, it's not.
All those rules are what no-coder consultants came up with long after the fact to sell books.
When you look into what Alan Key - who coined the term - said, by objects he pretty much meant separate processes communicating with each other through messages.
Not saying he was right - it's a useful concept, but I wouldn't say it fits all applications, neither it really needs a name for it (and better one would be "Worker Oriented Programming").
But it definitely has nothing in common with the actual "OOP" languages and he said so himself.
>It's a whole paradigm using them in specific ways.
No, it's not.
All those rules are what no-coder consultants came up with long after the fact to sell books.
When you look into what Alan Key - who coined the term - said, by objects he pretty much meant separate processes communicating with each other through messages.
Not saying he was right - it's a useful concept, but I wouldn't say it fits all applications, neither it really needs a name for it (and better one would be "Worker Oriented Programming").
But it definitely has nothing in common with the actual "OOP" languages and he said so himself.
Anonymous · reply · 2026-07-21 17:47:44
>>25940
Just because you write "class" a lot doesn't mean you use OOP.
Just because you write "class" a lot doesn't mean you use OOP.
Anonymous · reply · 2026-07-21 17:48:46
>>25942
*Kay
*Kay
the-runtime-guy · reply · 2026-07-21 17:53:25
i would actaully want to evolve this thought >>25934 into something rigid, but information ive seen so far is either false, like here >>25924
>problem only: segregating your program state
nope, first OOP is about INTEGRATING data/state with code (function=>method), isolation comes as a bonus.
OR unrelated, like
>>25890
>overengineering
>>25890
>unnecessary abstraction
and other casy muratory red T-shirt babble
>>25893
>The evolution of Object Oriented Programming makes much more sense if you learn about it from that perspective. Learn how to implement classes and objects in raw C and you should get a better appreciation for what the style is actually good for (this guy gets it: >>25891).
that guy is a retard. if you implement something it is not sugar, sugar is a macrolang or an abstraction that utilizes known mechanics (aiming to improve its look, make it "sweet", thus "sugar") without introducing new, but OOP/object is a unique tech.
>>25895
>Classes and class inheritance
a peanut rustle - a little difference from prototype object model pioneered in JS. runtime must infer scheme from objects it encounters building these "classes" under the hat. there is also a "hidden class" term in JS, so classes or typedefs or structs are fine, other babble is unrelated.
--
im hodling to a bit more advanced thought - OOP is unnecessary and fragile at low-level, so it should be used only at higher levels by runtime brahmin
>problem only: segregating your program state
nope, first OOP is about INTEGRATING data/state with code (function=>method), isolation comes as a bonus.
OR unrelated, like
>>25890
>overengineering
>>25890
>unnecessary abstraction
and other casy muratory red T-shirt babble
>>25893
>The evolution of Object Oriented Programming makes much more sense if you learn about it from that perspective. Learn how to implement classes and objects in raw C and you should get a better appreciation for what the style is actually good for (this guy gets it: >>25891).
that guy is a retard. if you implement something it is not sugar, sugar is a macrolang or an abstraction that utilizes known mechanics (aiming to improve its look, make it "sweet", thus "sugar") without introducing new, but OOP/object is a unique tech.
>>25895
>Classes and class inheritance
a peanut rustle - a little difference from prototype object model pioneered in JS. runtime must infer scheme from objects it encounters building these "classes" under the hat. there is also a "hidden class" term in JS, so classes or typedefs or structs are fine, other babble is unrelated.
--
im hodling to a bit more advanced thought - OOP is unnecessary and fragile at low-level, so it should be used only at higher levels by runtime brahmin
Anonymous · reply · 2026-07-21 17:56:57
>>25943
if you do serious dev work for businesses but don't use encapsulation and abstract types you'll be out of a job once someone else has to take over whatever you're working on
go get a job and find out
if you do serious dev work for businesses but don't use encapsulation and abstract types you'll be out of a job once someone else has to take over whatever you're working on
go get a job and find out
Anonymous · reply · 2026-07-21 17:58:23
>>25946
>encapsulation and abstract types
Not OOP, it's just structured programming.
>encapsulation and abstract types
Not OOP, it's just structured programming.
Anonymous · reply · 2026-07-21 17:59:11
>>25947
>jobless AND retarded
nice
>jobless AND retarded
nice
Anonymous · reply · 2026-07-21 18:00:18
>>25948
Not an argument, jeet.
Not an argument, jeet.
Anonymous · reply · 2026-07-21 18:00:44
>>25886
watch this OP
https://www.youtube.com/watch?v=wo84LFzx5nI
watch this OP
https://www.youtube.com/watch?v=wo84LFzx5nI
Anonymous · reply · 2026-07-21 18:02:56
>>25945
>little difference from prototype object model pioneered in JS.
That's completely false. Self pioneered pure prototype based OOP, js was inspired by Self
Especially on the vm technology, it introduced a fuckton of techniques that made its runtime performance comparable to optimized C++
Self virtual machine technology is one of the foundations of modern high-performance dynamic language runtimes (java, V8,...)
But aside from that, the more I read about prototype based OOP, the more I'm convinced it's superior to class based and that should have been the standard OOP implementation
>little difference from prototype object model pioneered in JS.
That's completely false. Self pioneered pure prototype based OOP, js was inspired by Self
Especially on the vm technology, it introduced a fuckton of techniques that made its runtime performance comparable to optimized C++
Self virtual machine technology is one of the foundations of modern high-performance dynamic language runtimes (java, V8,...)
But aside from that, the more I read about prototype based OOP, the more I'm convinced it's superior to class based and that should have been the standard OOP implementation
Anonymous · reply · 2026-07-21 18:04:17
>want to do thing
>declare data needed to do thing
>do thing
you need to stop here
>oop
>declare data needed to do thing
>do thing
you need to stop here
>oop
Anonymous · reply · 2026-07-21 18:11:35
>>25949
at least curry niggers gain employment
now go fill out a job application
at least curry niggers gain employment
now go fill out a job application
Anonymous · reply · 2026-07-21 18:14:29
>>25886
When you take a course on OOP the first thing you'll be introduced with will be some variation of interface Animal implemented by Dog that does print("woof") and Cat that does print("meow") and this one simple trick glitches 99% of people. It seems nobody can let go of this idea that they have to categorize every real world concept into some neat taxonomy tree and their code then will be bug free and optimal. Turns out this is retarded for real work. For example in games you might be temped to have common root for a player, box, light, because after all they're all "objects" and have positions in space. Except now when you try to apply what you were taught shit breaks down. Things cannot move on their own, they have to be updated externally by physics, they cannot draw themselves because graphics APIs have moved on from that in the past 30 years. Of course, computers are sufficiently fast that you can just force things. What nobody told you is that class instance object is categorically different from physical objects. An example of useful abstraction would be CharacterMover interface which is implemented by MainPlayer, NPC, NetworkPlayer classes.
When you take a course on OOP the first thing you'll be introduced with will be some variation of interface Animal implemented by Dog that does print("woof") and Cat that does print("meow") and this one simple trick glitches 99% of people. It seems nobody can let go of this idea that they have to categorize every real world concept into some neat taxonomy tree and their code then will be bug free and optimal. Turns out this is retarded for real work. For example in games you might be temped to have common root for a player, box, light, because after all they're all "objects" and have positions in space. Except now when you try to apply what you were taught shit breaks down. Things cannot move on their own, they have to be updated externally by physics, they cannot draw themselves because graphics APIs have moved on from that in the past 30 years. Of course, computers are sufficiently fast that you can just force things. What nobody told you is that class instance object is categorically different from physical objects. An example of useful abstraction would be CharacterMover interface which is implemented by MainPlayer, NPC, NetworkPlayer classes.
Anonymous · reply · 2026-07-21 18:22:29
>>25886
>You're just defining an "object", assigning traits and creating it's own unique internal functions.
Are you actually just defining an "object"? Or are you defining 2 objects, in which case you also need 2 more definitions: how one maps / interacts with the other, and vice versa. Or are you defining 3 objects, in which case you need 6 more definitions: how one interacts with two others, x3. Or are you defining 4 objects, in which case you need 12 more definitions...
You see how retarded it gets as you start to encapsulate everything in custom objects. As opposed to functional programming where, if you're doing it correctly, you only ever have 1 state object.
>You're just defining an "object", assigning traits and creating it's own unique internal functions.
Are you actually just defining an "object"? Or are you defining 2 objects, in which case you also need 2 more definitions: how one maps / interacts with the other, and vice versa. Or are you defining 3 objects, in which case you need 6 more definitions: how one interacts with two others, x3. Or are you defining 4 objects, in which case you need 12 more definitions...
You see how retarded it gets as you start to encapsulate everything in custom objects. As opposed to functional programming where, if you're doing it correctly, you only ever have 1 state object.
Anonymous · reply · 2026-07-21 18:32:46
>>25955
You are defining 2 objects where the one delegates to the other in cases when it can't answer to a message. Just like you pass a function in another function
Arguinig like OOP is in contraposition of functional paradigm is a braindead retarded statement
You are defining 2 objects where the one delegates to the other in cases when it can't answer to a message. Just like you pass a function in another function
Arguinig like OOP is in contraposition of functional paradigm is a braindead retarded statement
Anonymous · reply · 2026-07-21 18:34:49
>>25886
low entery barrier and you can do stupid retarded shit with it. and there are a plenty of jeets and illiterates out there.
low entery barrier and you can do stupid retarded shit with it. and there are a plenty of jeets and illiterates out there.
Anonymous · reply · 2026-07-21 18:35:02
>>25886
I wouldn't make a minecraft mod in a single giant Main class lol
I wouldn't make a minecraft mod in a single giant Main class lol
Anonymous · reply · 2026-07-21 18:40:01
>>25945
>if you implement something it is not sugar, sugar is a macrolang or an abstraction that utilizes known mechanics (aiming to improve its look, make it "sweet", thus "sugar") without introducing new, but OOP/object is a unique tech
it's a sugar over tagged void*, hand-written vtables and storing function pointers
the only "new" tech is that compiler is aware of these idioms and can optimize them out
>if you implement something it is not sugar, sugar is a macrolang or an abstraction that utilizes known mechanics (aiming to improve its look, make it "sweet", thus "sugar") without introducing new, but OOP/object is a unique tech
it's a sugar over tagged void*, hand-written vtables and storing function pointers
the only "new" tech is that compiler is aware of these idioms and can optimize them out
Anonymous · reply · 2026-07-21 18:41:00
>>25888
I'm an American, I don't need a use case to carry a gun.
I'm an American, I don't need a use case to carry a gun.
Anonymous · reply · 2026-07-21 18:44:50
>>25954
Not their fault.
Classes as understood by C++ and derived "OOP" languages are wrong.
What they call "interface" is what actually* a class is - a class of different types sharing an interface, instead of just a single type that C++ (and derived) classes are.
Of course he quickly realized (but not understood, since Bjarne is just a dumb engineer, not a proper computer scientist) his mistake and tried to implement the correct behavior through inheritance and method overloading which obviously made things much much worse...
Proper classes are an open schema - where you model more and more things as you want/need them and add them to existing code without any issue.
Wrong C++ classes are a closed model - which encourages modeling everything in advance, because if you forget something you will be in a world of pain when you'll have to add it in the future.
*more closely
Not their fault.
Classes as understood by C++ and derived "OOP" languages are wrong.
What they call "interface" is what actually* a class is - a class of different types sharing an interface, instead of just a single type that C++ (and derived) classes are.
Of course he quickly realized (but not understood, since Bjarne is just a dumb engineer, not a proper computer scientist) his mistake and tried to implement the correct behavior through inheritance and method overloading which obviously made things much much worse...
Proper classes are an open schema - where you model more and more things as you want/need them and add them to existing code without any issue.
Wrong C++ classes are a closed model - which encourages modeling everything in advance, because if you forget something you will be in a world of pain when you'll have to add it in the future.
*more closely
Anonymous · reply · 2026-07-21 18:44:59
PDS: invoking "you must not have a job" in place of an argument is an automatic L on /g/.
Anonymous · reply · 2026-07-21 18:47:16
>>25956
>You are defining 2 objects where the one delegates to the other in cases when it can't answer to a message
I covered that situation are you retarded? Every new object defined is a new node on a graph. For the new node definition to be relevant to the program state, there needs to be at least one delegate written to create a connection to another node.
*IF* you're only defining one or two objects, that's fine. But in practice, "enterprise" OOP code ends up looking like 50+ different nodes, connected by a clusterfuck of delegates that connect in every which direction. And then you need to add a new feature, so you add a new object definition. But then you're writing 15 other delegate functions to connect it to all the other objects that it's relevant to. And then you need to modify an existing object definition, so you're also reworking 12 other delegates for that object, and another 30 downstream from them.
>You are defining 2 objects where the one delegates to the other in cases when it can't answer to a message
I covered that situation are you retarded? Every new object defined is a new node on a graph. For the new node definition to be relevant to the program state, there needs to be at least one delegate written to create a connection to another node.
*IF* you're only defining one or two objects, that's fine. But in practice, "enterprise" OOP code ends up looking like 50+ different nodes, connected by a clusterfuck of delegates that connect in every which direction. And then you need to add a new feature, so you add a new object definition. But then you're writing 15 other delegate functions to connect it to all the other objects that it's relevant to. And then you need to modify an existing object definition, so you're also reworking 12 other delegates for that object, and another 30 downstream from them.
Anonymous · reply · 2026-07-21 18:50:06
>>25886
from the surface it seems like a neat idea but once you delve deeper you will notice that it's such a flawed way to model a program.
from the surface it seems like a neat idea but once you delve deeper you will notice that it's such a flawed way to model a program.
Anonymous · reply · 2026-07-21 18:51:01
>>25962
>No real code base uses OOP.
>Everyone does procedural (now with a bit of functional) programming
sounds like an unemployed to me
>No real code base uses OOP.
>Everyone does procedural (now with a bit of functional) programming
sounds like an unemployed to me
Anonymous · reply · 2026-07-21 18:51:45
>>25964
oh and btw associating methods to data is not OOP
oh and btw associating methods to data is not OOP
Anonymous · reply · 2026-07-21 18:53:47
>>25961
>C++ classes are a closed model
what
>C++ classes are a closed model
what
Anonymous · reply · 2026-07-21 18:54:41
>>25886
Because once you work with Rust, Go and similar modern languages, you realize that you need is Structs and Traits (Interfaces). Inheritance and similar things that are in OOP but not in Rust are a fucking meme.
Because once you work with Rust, Go and similar modern languages, you realize that you need is Structs and Traits (Interfaces). Inheritance and similar things that are in OOP but not in Rust are a fucking meme.
Anonymous · reply · 2026-07-21 18:55:15
>>25886
OOP is great if used properly. The problem is that some retards overuse it and that adds unnecessary abstractions and obfuscations that make the code hard to interpret, edit, and debug.
OOP is great if used properly. The problem is that some retards overuse it and that adds unnecessary abstractions and obfuscations that make the code hard to interpret, edit, and debug.
Anonymous · reply · 2026-07-21 18:55:38
>>25968
pretty much
pretty much
Anonymous · reply · 2026-07-21 18:56:42
>>25969
>real OOP has never been tried
>real OOP has never been tried
Anonymous · reply · 2026-07-21 18:57:49
>>25967
Interfaces are additive.
Classes are not (unless you count extremely flawed multiple inheritance in C++, which derived languages - rightfully - not implemented).
Interfaces are additive.
Classes are not (unless you count extremely flawed multiple inheritance in C++, which derived languages - rightfully - not implemented).
Anonymous · reply · 2026-07-21 18:59:19
>>25938
>computing is not immune to marketing, religion and ideology
Exhibit A: Rust
>computing is not immune to marketing, religion and ideology
Exhibit A: Rust
Anonymous · reply · 2026-07-21 19:00:03
>>25966
Yeah it is, no true ooper
Yeah it is, no true ooper
Anonymous · reply · 2026-07-21 19:03:17
>>25973
Trannies live in your head rent free.
Trannies live in your head rent free.
Anonymous · reply · 2026-07-21 19:08:43
>>25972
there is nothing flawed about multiple inheritance in C++ when it comes to inheriting interfaces without member variables
there are also C++20 concepts if you like traits
there is nothing flawed about multiple inheritance in C++ when it comes to inheriting interfaces without member variables
there are also C++20 concepts if you like traits
the-runtime-guy · reply · 2026-07-21 19:09:51
>>25951
okay maybe maybe, but people know nothing about Self (if it was so great, wheres its runtime?)
>it's superior to class
superior is when 50% or more, overhelmengly, these are peanut rustle (nobody hears the tragedy) 1% or less - is my point. prototype is better, but not much better.
>>25959
>sugar over tagged void*, hand-written vtables and storing function pointers
its not sugar because nobody does OOP in a language that doesnt have objects, your vtable-mumble-jumble is retarded and alien - no thanks. i did trampolines in C btw, to bind function to data.
https://share.gemini.google/6bsHhhuk7d42
everything is sugar because everything decomposes to 1 and 0.
okay maybe maybe, but people know nothing about Self (if it was so great, wheres its runtime?)
>it's superior to class
superior is when 50% or more, overhelmengly, these are peanut rustle (nobody hears the tragedy) 1% or less - is my point. prototype is better, but not much better.
>>25959
>sugar over tagged void*, hand-written vtables and storing function pointers
its not sugar because nobody does OOP in a language that doesnt have objects, your vtable-mumble-jumble is retarded and alien - no thanks. i did trampolines in C btw, to bind function to data.
https://share.gemini.google/6bsHhhuk7d42
everything is sugar because everything decomposes to 1 and 0.
Anonymous · reply · 2026-07-21 19:10:04
>>25888
usecase for not hating OOP
usecase for not hating OOP
Anonymous · reply · 2026-07-21 19:11:43
>>25891
This
This
Anonymous · reply · 2026-07-21 19:12:43
>>25974
I guess all languages are OO then
I guess all languages are OO then
Anonymous · reply · 2026-07-21 19:16:07
>>25975
Whatever the merits of Rust, you can't reasonably deny there was also a cultish mania surrounding its proliferation. Internet discussions everywhere were flooded by non-thinking shills chanting buzzwords like "memory safety" and spamming bug statistics from 10 years ago. They'd come armed with with an assload of fallacious retorts to deploy against even the mildest and most reasonable skeptics.
Rust was easily the most intensely shilled programming language since "write once run anywhere" Java.
Whatever the merits of Rust, you can't reasonably deny there was also a cultish mania surrounding its proliferation. Internet discussions everywhere were flooded by non-thinking shills chanting buzzwords like "memory safety" and spamming bug statistics from 10 years ago. They'd come armed with with an assload of fallacious retorts to deploy against even the mildest and most reasonable skeptics.
Rust was easily the most intensely shilled programming language since "write once run anywhere" Java.
Anonymous · reply · 2026-07-21 19:17:59
>>25980
Not true at all. Though if you want to play semantic word games by vaguifying the term "associated" you ought to question your life choices.
Not true at all. Though if you want to play semantic word games by vaguifying the term "associated" you ought to question your life choices.
Anonymous · reply · 2026-07-21 19:20:35
>>25982
vec_add(v1, v2)
is the same as
v1.add(v2)
it's just syntactic difference
vec_add(v1, v2)
is the same as
v1.add(v2)
it's just syntactic difference
Anonymous · reply · 2026-07-21 19:21:40
>>25976
>inheriting interfaces
Yes, because they're interfaces* - actual classes of types.
Instead of this shitty very-specific concept of struct+vtable C++ introduced and called "class" (and languages like Java and C# adopted) and "OOP" proponents encouraged people to use for everything.
In the beginning at least, thankfully they came to their senses in the (relatively) recent times and stopped spouting this bs.
*and "inheriting" actually means "implementing" here, you're not inheriting anything
>inheriting interfaces
Yes, because they're interfaces* - actual classes of types.
Instead of this shitty very-specific concept of struct+vtable C++ introduced and called "class" (and languages like Java and C# adopted) and "OOP" proponents encouraged people to use for everything.
In the beginning at least, thankfully they came to their senses in the (relatively) recent times and stopped spouting this bs.
*and "inheriting" actually means "implementing" here, you're not inheriting anything
Anonymous · reply · 2026-07-21 19:22:21
>>25977
>if it was so great, wheres its runtime?)
Inside every "fast" modern VM that uses technologies created/modernized on VM by Selfie
> Adaptive optimization
> Inline caching
> Polymorphic inline caches (PICs)
> Type feedback
> Speculative optimization
> Dynamic deoptimization
> Object maps / hidden classes / shapes
> Fast property access
> Generational garbage collection techniques
> Escape analysis
> Runtime profiling for optimization
> On-stack replacement (OSR) for optimized code execution
> Adaptive recompilation
>is my point. prototype is better, but not much better.
Your point is not really intelligible. Maybe try to rephrase it
>if it was so great, wheres its runtime?)
Inside every "fast" modern VM that uses technologies created/modernized on VM by Selfie
> Adaptive optimization
> Inline caching
> Polymorphic inline caches (PICs)
> Type feedback
> Speculative optimization
> Dynamic deoptimization
> Object maps / hidden classes / shapes
> Fast property access
> Generational garbage collection techniques
> Escape analysis
> Runtime profiling for optimization
> On-stack replacement (OSR) for optimized code execution
> Adaptive recompilation
>is my point. prototype is better, but not much better.
Your point is not really intelligible. Maybe try to rephrase it
‹ Newer posts Page 2 of 6 Older posts ›
Reply to this thread
Posting requires a durable account or a TripPass. Reading remains available.
Sign in or create or attach a TripPass to post. Browsing is open.