Just try something else and you'll see it's failings, it's as simple as that. The issue with OOP is that not everything is a nail, but everyone keeps pretending a hammer is all you ever need

>>109327832
use case for hating OOP?

>>109328052
contributing to the linux kernel for starters

it's unnecessary abstraction and boilerplate. extra work for no gain. it doesn't improve readability/comprehension either.
you could be doing something actually productive with your time instead of overengineering a problem and writing class, __init__, and self everywhere.
functions are all you need. data should be separate from functions, not bundled.
ask an LLM for the difference between procedural and object-oriented code.

>>109327832
>why does everyone hate OOP?
they worked at retarded companies where everyone is a schizophrenic so every Car must be a final Vehicle or else Bobby the staff engineer gets weirder and takes showers less often
OOP is great when it's syntactic sugar over structs, with an occasional convenience of virtual dispatch

>>109328058
I don't think you know what you're talking about for one thing and for another I don't think you've ever written a line of kernel source code in your entire worthless fucking existence

>>109328071
This is all true especially for python, and also for a lot of java devs who never learned anything else.
But it's worth noting that in older, lower-level languages like C, you didn't have all the convenient built-in rich types like lists and dictionaries and and you couldn't just write like you had infinite CPU and memory all the time as often happens in python. 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: >>109328075).

>>109327832
you can completely ignore anyone who blindly hates on OOP.
if someone can't offer nuanced view on one of the most widely used programming paradigms you know you're dealing with an edgy neckbeard.

>>109327832
Using classes everywhere, which C# and Java actually require, adds a lot of "boilerplate" to the code.

Python is flexible, you can write in an OOP style or functional style or however you want.

Classes are never really necessary, it's more of a design choice. People who think classes should always be used because they believe in OOP dogma end up writing unnecessarily complex code. Classes and class inheritance can actually "box you in" if not used properly (meaning you hve to do a lot of refactoring to make certain changes). But classes have uses and there's nothing wrong with using them judiciously. If you find yourself passing the same group of parameters to different functions, your code would probably be better if you created a class, made the repeated parameters into class members and made the functions receiving the repeated parameters into methods of the class. Also, textbooks explain classes in retarded ways, like making the "circle" class a derived class of the "shape" class and so on, which sets people up for using inheritance wrong. You should actually avoid inheritance most of the time and use composition instead.

>>109328106
look
emulating methods with function pointers doesnt count

>>109328212
It's widely used because of marketing.

>>109327832
>everyone hates OOP
>99% of software is built using OOP
doesn't add up. you got psyopped

>>109328358
use case for methods?

>>109327832
OOP isn't just classes, and Python doesn't have/need what people hate about "OOP"

>>109327832
it can get needlessly complex in the hands of first timers. Its obviously very useful if you write a program with a deck of cards; we all understand the hierarchy of deck, card, suite, color, etc. However, it can become a mess when you don't understand how to best abstract your classes.
Using vidya, many students probably wouldn't understand how a fire spell would fall under magic or an uppercut under physical damage. Or if they do, it would devolve into an autismo storm over "hurr what if you cause a fire DOT on top of the physical..." whatever.
tl;dr most people suck at using classes unless its applied on something that's already easily understood.

>>109328071
>clases, __init__, and self
>python oop
maybe try using an actual programming language? and no javascript is not a good option either

>>109328232
>You should actually avoid inheritance most of the time and use composition instead.
Why? I actually like Inheritance more and most of the time it makes more sense to me and works better, this is one of those things I've never been able to understand. Apparently in Java this is strongly encouraged with interfaces and everyone uses them to the point of having an Abstract Class becomes an "antipattern", but everytime I ask why that's better than building things around inheritance they always say "the architecture is like that" or "it's built better like that", so why anon? I don't get it

>>109327832
it owns them

>>OOP is good because java has libraries
kek

>>109327832
There are places for OOP. Look at things like composition vs inheritance. Casey Muratori has a great talk on the shortcomings of OOP.

The easiest way to explain it is that sometimes all you really need are functions. Everything does not need to be a class nor does everything need to be an object.

Keep programming and learn the fundamentals with Python. Get a hang of the basics then try to master things like context managers, list comprehensions, lambdas, and decorators. From there broaden your horizons a bit. See how things are done in common lisp, haskell, or Scala.

Programming can be intellectually rewarding. Scala, in particular, is very powerful. You can learn a great deal about type theory just from that one language. Scala runs natively, transpiled to JS (Scala to JS), and on the JVM. I highly recommend it AFTER you see what Python has to offer.

>>109328358
>emulating methods with function pointers doesnt count
But that's how methods are implemented under the hood?

>>109327832
The problem will come when you start making changes to existing classes, Pranjesh.

>>109327832
I used to be dogmatic in my hate for OOP, because I projected my personal dislike of a person onto the software programming paradigm itself. It was very immature of me. That being said, I see a lot of OOP, and I can see why a lot of people would like the paradigm. It's like a tree, and there are branches that descend from the tree.

Eventually, if you had defined enough methods, you would basically no longer be writing in the programming language anymore. Most of what you are doing would be working with a fuzzy selector in an IDE or vim/nano/emacs, you'd be basically speaking your own "language", which each developer generally ends up inventing as they go along. Some people really hate how other people write code. Like it makes them violently angry and it's weird.

post ai era code don't be matter anymore, it's like caring about taste of how compiled binary looks.

if caveman crug want make one operation on data, crug make function that unga one bunga

if caveman crug want make many operation on data and persist it like thing, crug make class that have many function that unga different bunga

sometimes caveman crug must bash rock, just need to unga bunga. sometimes caveman crug need to make fire and unga many different bunga.

caveman oog look at too many wall scratching by other caveman who sometime do not unga bunga. oog get confused, slam arms on ground and yell about paradigm. caveman crug just unga bunga.

>>109328071
Classes are for encapsulating related logic and data though.

Imagine writing a GUI App without classes.... I guess you can but you'd had related data accessable in the global scope

>>109328954
>I actually like Inheritance
Ask an ai chatbot for the top five problems with OOP inheritance, it will be enlightening to you.

But, obviously, if you add something to a base class now every derived class has that. It might seem easy to work with in the beginning but it can easily create a disaster.

>>109330190
>Imagine writing a GUI App without classes
Take a look at Tcl/Tk.

>you'd had related data accessable in the global scope
You don't need classes for encapsulation. Everything classes do, you can do without classes. They are more about how you structure the code.

>>109328383
That often means you are missing critical details. Both can be true. Happens all the time and tedious midwit shitposters never learn.

>>109328442
>Python doesn't have/need what people hate about "OOP"
Sort of true, but fact is that OOP-minded programmers, especially novice ones, often implement bad designs in Python because they come from a Java background and instinctively reach for class definitions as the default code organization. So instead of, for example, reading input data into a generic dictionary and using generic functions to process the data, they wrap everything in a class first and bolt on the methods (whether or not there are important security reasons for using such an approach).

I've seen numerous variants of this pattern from python devs.

>>109327832
OOP is when you make a bunch of files that do nothing instead of adding a comment line

>>109329054
this only really clicked for me once I wanted to refactor a piece of code I haven't looked at in a while and first had to hunt down all the code that might run during a call and check whether it mutates the object.
It might be that pain is necessary to learn this lesson, but I think the elegance of composition should be self-evident if you give it a fair shot

>>109327832
>why does everyone hate OOP?
because in most cases it's taught wrong, and because people don't want to accept the possibility of being taught something wrong, they instead draw conclusions that the whole paradigm is just bad, for reasons more convoluted than the problems they have with OOP

something something getting banana requires spawning a gorilla complete with a jungle

>>109331624
It is "taught wrong" because there is no OOP.
The most common interpretation of OOP is that you should wrap everything in a class, as C++ (wrongly) understands it - a combo of a struct and a vtable for its associated methods.

But even the very first users of C++ didn't do that. What attracted them to C++ over C were better facilities for generic programming and operator overloading - which enables better, easier to use abstractions and code reuse.

OOP is a red herring - no one really ever gave a shit about it, except for academics and consultants - as their job is about speaking and not doing actual work and OOP gives them this nice sounding framework to talk about programming.
And since they're the vocal ones of the programming community - they shaped the discourse.

>>109327832
i'm a c# dev and the truth is nobody even writes proper OOP applications anymore (except for DDD cultists I guess). the dream of modeling your domain using objects and having a rich network of black boxes communicating with each other is not a thing anymore, if it even really ever was. modern web applications are highly procedural in their overall design and tend to explicitly separate data and behavior within the domain model (much to the chagrin of martin fowler).

the end result is it feels like you're largely dealing with OOP as a side effect of the language's design rather than as a meaningful design paradigm within your own application, and the whole thing just ends up feeling grossly overengineered/overabstracted and harder to reason about as a result

>>109327832
>why does everyone hate OOP?

oop literally took over everything, lel. what a statement. only a neet would say that.

OOP solves one problem and one problem only: segregating your program state into smaller pieces that can be reasoned about in isolation and whose type invariants are easier to combine to form program invariants.

OOP does not solve the problem of when to stop subdividing so you don't end up with shit interfaces that get in the way of refactoring or optimizing. OOP does not solve the problem of giving your objects an easy-to-use interface for your business-logic scripts. OOP does not solve the problem of making code more legible. OOP does not solve the problems data-oriented design solves. OOP does not solve the problem of making your code easier to debug. OOP does not solve the problem of which bits of program state should be statically allocated, thread-allocated or dynamically allocated.

The OOP books, classes and confs I followed usually come with laughably bad ideas to solve the aforementioned problems. And some common features of languages designed around OOP such as garbage collectors make it impossible to correctly solve them without highly unidiomatic constructs or FFIs.

Also, OOP isn't "using classes." It's a whole paradigm using them in specific ways.

>>109327832
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

>>109332720
I just checked out his social media and holy shit, he looks like he hasn't slept in weeks and his posts suggest a rather severe case of AI psychosis.

>>109332757
maybe it's Maybelline
maybe it's methamphetamine

>>109327832
No experienced professional coders hate OOP, it's normally these people who shill C and the C language book. They are the same kind of people who run archlinux on a lenovo.

The reality is they've never had to produce, maintain and add features to an actually useful, commercial application that makes money.

>>109332175
you sound like a retard

>>109328358
"emulating"? that's what methods ARE

I find there are easier ways to scope the problem that don't require you to put all the data in one object and it prevents things like unintended access / scope pollution between methods.
Regular functions and closures always end up being simpler to write and execute in my experience. I end up not needing to typedef nearly as much since I just pass scope around via parameters instead of methods with a self/this pointer. (so the same thing but static dispatch)

>>109332800
he is

>>109328044
>. The issue with OOP is that not everything is a nail, but everyone keeps pretending a hammer is all you ever need
This is a shit take honestly. objects are a computation abstraction just like functions
Some language builds computation on top of objects and everything can be an object

>>109328071
> it's unnecessary abstraction and boilerplate
> nstead of overengineering a problem and writing class, __init__, and self everywhere.
In python (or in any class-based dynamic OO languages) classes are no more than documentation. Python specifically is pretty flexible to avoid any over-engineering traps you may fall in other class-based languages like C++ and Java

>>109328232
>. People who think classes should always be used because they believe in OOP dogma end up writing unnecessarily complex code
Class-instance OO is not the only possible OOP implementation

OOP being bad - is a haptic thought, meaning its not a thorough thought that basically comes from low-level programming (compiled code)

>>109327832
It pays the bills unlike most hobbyist crap. Have you never seen a lot of salt directed .NET developers for example?

>>109329062
maybe anon meant explicit inheritance and polymorphism and all that OOP jazz? hell if I know

>>109327832
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.

>>109333068
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.

>>109327832
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.

>>109333226
you're definitely unemployed

>>109332616
>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

>>109332616
>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.

>>109333268
Just because you write "class" a lot doesn't mean you use OOP.

>>109333334
*Kay

i would actaully want to evolve this thought >>109333050 into something rigid, but information ive seen so far is either false, like here >>109332616
>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

>>109328071
>overengineering
>>109328071
>unnecessary abstraction

and other casy muratory red T-shirt babble

>>109328175
>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: >>109328075).

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.

>>109328232
>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

>>109333351
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

>>109333437
>encapsulation and abstract types
Not OOP, it's just structured programming.

>>109333447
>jobless AND retarded
nice

>>109333453
Not an argument, jeet.

>>109327832
watch this OP
https://www.youtube.com/watch?v=wo84LFzx5nI

>>109333405
>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

>want to do thing
>declare data needed to do thing
>do thing
you need to stop here
>oop

>>109333465
at least curry niggers gain employment
now go fill out a job application

>>109327832
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.

>>109327832
>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.

>>109333638
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

>>109327832
low entery barrier and you can do stupid retarded shit with it. and there are a plenty of jeets and illiterates out there.

>>109327832
I wouldn't make a minecraft mod in a single giant Main class lol

>>109333405
>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

>>109328052
I'm an American, I don't need a use case to carry a gun.

>>109333571
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

PDS: invoking "you must not have a job" in place of an argument is an automatic L on /g/.

>>109333710
>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.

>>109327832
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.

>>109333816
>No real code base uses OOP.
>Everyone does procedural (now with a bit of functional) programming
sounds like an unemployed to me

>>109333861
oh and btw associating methods to data is not OOP

>>109333813
>C++ classes are a closed model
what

>>109327832
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.

>>109327832
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.

>>109333909
pretty much

>>109333912
>real OOP has never been tried

>>109333898
Interfaces are additive.
Classes are not (unless you count extremely flawed multiple inheritance in C++, which derived languages - rightfully - not implemented).

>>109333226
>computing is not immune to marketing, religion and ideology
Exhibit A: Rust

>>109333881
Yeah it is, no true ooper

>>109333959
Trannies live in your head rent free.

>>109333941
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

>>109333491
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.

>>109333774
>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.

>>109328052
usecase for not hating OOP

>>109328075
This

>>109333966
I guess all languages are OO then

>>109334000
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.

>>109334099
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.

>>109334151

vec_add(v1, v2)

is the same as

v1.add(v2)

it's just syntactic difference

>>109334061
>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

>>109334071
>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

>>109334135
>"memory safety" and spamming bug statistics from 10 years ago.
It's more relevant than ever now that AI is finding vulnerabilities en masse.

>>109334206
it's less relevant than ever now that AI is finding (and fixing) all the vulnerabilities

>>109334236
>AI
>fixing
>it was real in my head
Maybe in the future.
Of course assuming AI models will stay open and they'll keep disclosing their findings.

File: 1783712573462592.webm (3.96 MB, 720x576)

3.96 MB WEBM

>>109334293

>>109334191
>try to rephrase it

okay - a nothingburger, hehe. doesnt matter, objects are objects, i have no time for bikeshedding babble

>Inside every "fast" modern VM that uses technologies created/modernized on VM by Selfie

those arent technologies, those are some marketing word salad. "hidden classes" are only JS related and were described by runtime developer AFAIK.

real technology sounds like:

> string interning
> constant folding

>>109328052
You are a heckin' valid rustdev

>>109333334
>separate processes communicating with each other through messages
Yes, that's OOP, and that's much more than "using classes."

>>109327832
OOP is ok when it’s within a super on-rails language/framework. where basically you’re filling in prebuilt/builtins with your app logic. randomly using OOP/classes in eg: a Node api is psychopath behavior

scala is fun because it removes most of the boiler plating of oop and has some functional stuff like currying and tail recursion. most of the time you are using the `case class` which creates something that behaves like a haskell adt.

>>109334172
Until you realize that the "v1" object class doesn't just encapsulate the data { x, y, z }, it also represents a local displacement on a scenegraph represented as {parentNode, x, y, z }, which is being matrix transformed by parent rotation / scale nodes, and you didn't realize the ".add" method represents addition in local space not world space, so now your .add {0, 0, 10} just caused your character to explode off the map instead of making him jump up 10 units and you have no idea why.

Meanwhile your vec_add function you look at the code and see it's one line: return {v1.x + v2.x,... and you know it's a local transform so you look for a vec_displace or whatever the correct world-transform function is.

That's the problem with OOP turning all state into black boxes. Sometimes shit doesn't work as expected and you have no idea why because you thought it was better to hide the internals. But then you end up needing to look at the internals anyway, defeating the purpose.

>>109334815
what are you on about

>>109328075
/thread

I don't even know what OOP is. I know it means object oriented programming, but have no idea what that entails.

>>109334677
I've never written a line of rust in my entire life
I use GNOME btw

>>109334854
That

vec_add(v1, v2)

is not always just syntactic difference to

v1.add(v2)

because a member function might trigger a whole cascade of second-order effects (tree dirtying, event triggering, intermediate variable recalculations, ...) that you need to look into the black boxes to be sure of.

Meanwhile when your codebase only has pure functions, you are guaranteed to know that the effects of function calls are only those explicitly defined in the function.

>>109334950
the function could still do all of that

>>109334495
>okay - a nothingburger, hehe. doesnt matter, objects are objects, i have no time for bikeshedding babble
Still waiting for you to make a point

> those arent technologies, those are some marketing word salad
They indeed are "technologies". Self proved at that time that vms runtime were not intrinsically *that* slow and they could achieve comparable performances of optimized C (or at least in the same order of magnitude)

https://en.wikipedia.org/wiki/Self_(programming_language)

They are the technologies on top of which modern vm achieved fast runtime performance

>>109334950
What a disingenuous piece of vomit. There's nothing stopping you from adding a socket in the v struct and doing retarded stuff. It will stay pure since it's passed as an argument.

>>109334983
Not if it's pure

>>109335009
>adding a socket in the v struct and doing retarded stuff. It will stay pure since it's passed as an argument.
If you're passing a socket and then "doing retarded stuff", then that was on you. The pure function just returned a value. Any "retarded stuff" that happened was because you used the return value to change the socket object itself.

Meanwhile, with OOP the member could be "doing retarded stuff" to the socket, and if the object's state is hidden as private variables (which is generally best practice), you have no way to stop it without refactoring the class.

Or, as is often the case, you're working with someone else's scene library and have no way to refactor it yourself to stop it from doing retarded stuff, so instead you're begging on GitHub to have them change it.

>>109334950
>you need to look into the black boxes
you don't need to do that

File: 1783433302367134.jpg (48 KB, 677x680)

48 KB JPG

>>109327832
OOP will most likely trick you into making really bad architectural desitions. Having a simpler but flexible language will help you make faster software, and focus on the logic, instead of spending so much time fighting bad organisation. Having all these scopes is bad, and a beginner would benefit a lot by making most classes static. Looking back at my C# code, it is a hot mess, where avery file contains a class, and every class has a bunch of event bullshit to listen to other classes. It was a spiderweb where I was in little controll of how things worked together, and controlling the flow of the entire program, makes stuff a lot easier, for a solo dev

>>109327832
>why does everyone hate OOP?
I don't. it's mostly hated by pseuds trying to bring attention to themselves.

>>109334988
>They indeed are "technologies". Self proved at that time

okay okay, Self proved and Self was first, i asked the duck. i also recall there was a blog article of a dev who moved to Dart (or something) about hidden classes in JS, the text is copied to V8 site. also this one https://www.youtube.com/watch?v=hWhMKalEicY

...now i even recall he was a retard who was afraid of type assumptions.. but it is not related.

>make a point
okay, i start doubting hidden classes because they are hidden, read implicit, but explicit is better than implicit by the Zen. though my initial nothingburger stands strong.

>modern vm
bloated clusterfucks, ye, name any. they all cannot prove NOW (not at the time back back then when dinosaurs stompted the Earth) they are capable of doing programs, so programs are still compiled.

>>109333836
>Every new object defined is a new node on a graph
So what? You can't eliminate complexity to the extent you seem to think but move it on another space

The function execution in functional languages create a dynamical graph that can explode to be very wide and deep

> there needs to be at least one delegate written to create a connection to another node.
not really, unless you also include a primitive Object type

Btw you should really make a distinction between OOP in theory and practical implementation, because they differs significantly. OOP in "entities that can receive/send messages and forward them" like smalltalk/pharo and self, and between statically and dynamically typed class based OOP

In the formers, the language is not meant to be just the language isolated, but it's the sum of language+environment: Objects are "living" entities that can be inspected and modified at runtime. Development is meant to be like the LISP's REPL interactive development but arguably in a more powerful and flexible fashion. Complexity is tamed by the fact that you basically live in a debugger while developing https://www.youtube.com/watch?v=xhPlUaXpCU4

In statically typed class based OOP languages, I argue that a significant amount of cruft comes the strong coupling of traits and instance-representation and from the class-instance implementation of OO: almost all creational pattern arise as a workaround to deal with the strictness/limitation imposed by classes (when the receiver doens't know in advance the type or family type of the object received. The structural and (especially) behavioral ones actually emerges from common sense

for dynamically typed languages like python I don't even know why they didn't go with prototype based OO implementation and left out the concept of class directly instead of making the extra-step of implementing class as an object for instance factory

>>109335161
>Not if it's pure
tf does that even mean?

>>109330190
yk you can encapsulate without classes right?
>Imagine writing a GUI App without classes
I've done this. It's actually much nicer.

>>109327832
There's nothing wrong with OOP in principle, if you use it properly and aren't retarded with it, but it also makes it very easy to shoot yourself in the foot. You can however make nicely organized and easily extendable programs if you use it properly.

Professionally speaking you are very likely to encounter code that has been - unfortunately - written by retards and midwits and as such you will run across enormous OOP abominations almost certainly. Retards and midwits also tend to follow advice, so-called "best practices" and "design patterns" completely blindly, effectively based on dogma with no critical thinking involved and no consideration of advantages / disadvantages in the actual program being written. While these often-quoted best practices and design patterns do have legitimate uses and applications, when a dev turns his brain off and merely follows such things blindly the end-result is almost certainly going to be extreme complexity of the codebase for no actual benefit. This seems to happen VERY frequently and the result is always a clusterfuck.

>>109335216
That's what every tard thinks and is always wrong.

>>109335316
>okay, i start doubting hidden classes because they are hidden,
I don't understand what you mean by this. Hidden classes (which can be thought of "hidden objects") are just implementation details for runtime performance tuning on a different plane wrt the language semantics
It's just like doubting the endianess or the stack/register vm when talking about the python language or lua

prototype based OOP actually makes more sense than class based. If you want an object just create a object that can answer to some kind of messages. Classes gives you some more compile time guarantee as a compiler contracts and a little bit of free documentation in dynamically typed languages (which seems to treat classes more or less as a blueprint for an object). On the other hand they comes with a lot of downsides and the need of extra-language constructs (like "abstract", "interface", "package/namespace", etc...)

The paper "Organizing programs without classes" makes some good point on the benefits of classless OO implementation

https://bibliography.selflanguage.org/_static/organizing-programs.pdf

>>109333931
No, he said OOP when properly tried is great.

File: Untitled.jpg (164 KB, 1030x1296)

164 KB JPG

OOP is alright. the problem is orthodox OOP which started running rampant in the 90s due to certain cancerous books. people started treating it as a religion, completely disregarding alternative paradigms.

>>109335640
>prototype based OOP actually makes more sense than class based.

nope, a class is the base of an object. hiding it makes no good according to the Zen. classes are only bad in JS, because JS is prototype based, so classes are sugar over prototypes being sugar over hidden classes being sugar over C++ classes (for those V8/Chuckcha engines, excluding quickjs-like) - 's the definition of a clusterfuck.

>>109335906
> nope, a class is the base of an object.
No, it's not. It's an object devote to a specific creational pattern of other objects

> hiding it makes no good according to the Zen.
You are not hiding anything. On the opposite, adding classes you are adding a layer on top of objects
> lasses are only bad in JS, because JS is prototype based,
Again, classes are not necessary for objects to exists
> so classes are sugar over prototypes being sugar over hidden classes being
incorrect, again.
https://en.wikipedia.org/wiki/Prototype-based_programming

>>109335949
>devote to a specific creational pattern of other objects

nobody gets this mumble-jumble. class is a scheme, a map of an object. every object has it.

>adding classes
is inevitable, it will happen either statically by developer or dynamically by the runtime

>classes are not necessary
necessary. learn the craft, then argue.

>>109335686
maybe it started off as a religion but it turned into a cult and now it's basically just cargo cult

>>109335229
>OOP will most likely trick you into making really bad architectural desitions.
individual's skill issue blamed on the paradigm

>>109332616
>OOP does not solve the problem of when to stop subdividing so you don't end up with shit interfaces that get in the way of refactoring or optimizing. OOP does not solve the problem of giving your objects an easy-to-use interface for your business-logic scripts. OOP does not solve the problem of making code more legible.
no paradigm will magically resolve design and architecture decisions - those are the programmer's competences

>OOP does not solve the problem of making your code easier to debug.
it literally does
state being in a small and closed scope means you need to instantiate only a very small part of the program at a time to test and debug. in most cases you don't even need to spin up the whole application and can run only that small piece of code
unless someone is very deliberately breaking encapsulation, the state is guaranteed to be free from modification from outside its declared scope
of course if you write crap code with state leaking everywhere you won't get this advantage

> OOP does not solve the problem of which bits of program state should be statically allocated, thread-allocated or dynamically allocated.
no paradigm does
it's an implementation detail not within the scope of the paradigm

>>109336059
I accept your concession

>>109336059
> nobody gets this mumble-jumble
It's actually pretty simple. A class is not necessary for the existence of an object

Class in language like python are actually objects used to implement the creational pattern of class-instance. In class based OOP you can implement prototype creational pattern and in prototype based language you can emulate the class-instance one

> is inevitable, it will happen either statically by developer or dynamically by the runtime
Again, classes are not fundamental to OOP, they are a language design choice. Objects can exist without the concept of class, in a theoretical formulation (most of formal objects specification are classeless like lambda calculus with records, Cardelli's Object calculus, Prototype calculi (the one implemented by self,io and js)), just as in informal definition as in
> an object is a semantic entity that has state, behavior, and identity.
> https://en.wikipedia.org/wiki/Object_(computer_science)


> it will happen either statically by developer
No it wont

> or dynamically by the runtime
Can be avoided. Again, the hidden class concept is introduces just because performance tuning, it's not necessary

File: itwont.jpg (37 KB, 800x450)

37 KB JPG

>>109336298
>class is not necessary

necessary

>in language like python

classes

>classes are not fundamental to OOP

fundamental to the implementation of objects that are fundamental to OOP.

>Objects can exist without the concept of class

only imaginary objects. real objects exist with a blueprint that is called a class.

>in a theoretical formulation

we are not in the school mr.Teacher, no monoidal calculilusator allowed. only craft and pragmatismus.

>Can be avoided. Again, the hidden class concept is introduces just because performance tuning, it's not necessary

ye, im waiting when your supreme runtime will prove your supreme theory, until then, its all academic

>>109327832
everyone that programs long enough contracts (p)OOP sickness at some point
not everyone recovers

>>109336511
You could've said right away that you were retarded

>>109336511
https://bibliography.selflanguage.org/implementation.html
selflanguage.org

Quote (verbatim from the page’s abstract):
“To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information …”

---

To compensate for the absence of maps, our system uses implementation-level hyperontological schematics to transparently group objects cloned from the same prototype, providing data-type information in a way that’s visible to the machine but opaque to the programmer …

>>109336868
To compensate for the absence of hyperontological schematics, our system uses implementation-level zygogastric memo-fog prismatograms—a kind of hyperphlogiston nebulo-architecture to transparently group objects cloned from the same prototype, providing data-type information in a way that’s visible to the machine but opaque to the programmer …

>>109328071
do you think classes and oop are the same thing?

>>109335686
if you actually read the book, it clearly says "we studied a bunch of IRL codebases and observed these commonalities" not "hurr durr write your code like this and buzz the newbs when they do an "anti pattern"".
that was (((consultants))).

>>109335589
you are conflating java with oop.
java's retardation that everything must be an object is a huge reason why oop in practice is as bad as it is. java programmers, aka rajesh patel and his 300 million cousins, worship java because sun has a jeet founder, and bring that retardation everwhere they go, namely c++

>>109336868
> To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information
types are not the same as classes nigger, they are different concepts

Storing information about a function ('a -> 'a) **type** does not define nor it is a class and doesn't involves classes in any place you cretin

You seems rather confused to the point you are trying to bend commonly consolidated terminology in order to be right

>>109336868
I'm fairly sure it was already been established that Self implemented hidden classes under the hood for performance reasons (as stated in the link you posted) in this comment here >>109334191 and you can infer it was not out of necessity by keep reading
> To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information and **eliminating the apparent space overhead for prototype-based systems**

, so I don't understand how you could have thought that your comment was some kind of gotcha

Unlucky for you, you're a pathetic namefag so you can't play dumb and pretend you didn't know it already and we can see you keep collecting so many L in this thread

>>109336555
>namefag is retarded
Say it ain't so