>>26029
OOP is an application of objects that are based on classes, so basically yes, retard, classes are OOP

Why do people still care about concepts like OOP?
AI has solved programming

>>26031
>java's retardation that everything must be an object is a huge reason why oop in practice is as bad as it is.
wrong
it's actually halfassing or outright avoiding object orientation is what creates the typical unmaintainable mess in Java codebases. overengineering is only a small part of it and usually not that hard to refactor into reasonable code. bad code and architecture are skill issues and will be bad regardless of the language or paradigm
"is it possible to implement without an object?" is the most common wrong question to ask yourself when working in an OOP language. most things you indeed can implement without an object, but by doing so you forfeit advantages object orientation provides, while leaving the overhead of the language's optimization for being object oriented (for example, having to repeat the 'static' keyword everywhere because none of your code is instantiated)

as for pajeets, they'll write abhorrent code no matter the paradigm

>>26037
Programming is not just a problem to solve.

>>26038
> "is it possible to implement without an object?" is the most common wrong question to ask yourself when working in an OOP language
Otherwise you will end up with thousands of classes.

>>26040
number of classes is as useful of a metric as number of lines of code
ie. it's completely useless

>>26041
It's not a metric: you have to search through them to find one appropriate to use, create adapters to get real data, more than half of them would be just containers/records.

>>26035
>nothing is as pathetic as hiding crappy theory by renaming "class" to "plass" or alike
That wasn't even the point of my comment. You clearly can't follow a simple linear discussion since you repeated something that was told you in the beginning like you discovered it let alone the simple distinction between class, type and object
>opinion is forged.
You're clearly a low IQ retard, your opinion is worthless at most

>>26035
>who cares, my view dominates
That's arguable. I think the best way to describe the current shared view is more like "we found a way to bear with class-based OOP after we realized that the principle actually gets in the way". Because after decades of teaching and internalizing the dogma "class = object" it creates a kind of inertia that would require too much effort to get fixed and we rather find a way to live with it. At the end of the day what's actually matter in the industry is to ship a correct and fast executable artifact

indeed classes and polymorphism by inheritance lost a lot of its centrality in modern OOP. What's left about class, is a just a way to define a type and instantiate objects. In python people moved from inheritance as a standard mechanism of object modelling to DI, delegation and composition: ie moving more toward the prototype OOP; and on top of that the introduction of dataclasses can interpreted as a way to move from traditional class-based OOP principles

To me new OOP development directions scream: classes were not a really the good concept it seemed in theory, but now it's too late and changing completely the OOP model is not worth the effort

>>26042
>you have to search through them to find one appropriate to use
finding the right class is a literal non-issue, even in a large enterprise codebase

>create adapters to get real data, more than half of them would be just containers/records
what is "real data" and why do you need "adapters" to get it?

>>25891
My Animal quacks, so it's a final Duck!

>>26027
Not really sure but the Io programming language doesn't seems to implement hidden classes btw, you may want to look into that
https://iolanguage.org/

>>26043
seethe and dilate tranny, hehehe

>>26044
>decades of teaching

sorry am not a demagogue as yourself, i kinda need pragmatismus: yes - yes, no - no. you should follow the whole thought instead of babbling around, then you know what was concluded. and make yerself a name nobodyfag

>>26047
again, follow the whole thread new nonamefag, the "class" or whatever you name it is an inevitable companion of an object. reasons are obvious.. lets see..

>>25886
>why does everyone hate OOP?
Faggots like Linus Torvalds do it to sound cool and the sheep follow. The way you know that OOP isn't bad is how pretty much every major application has been written in an object-oriented language.

>>26047
>https://iolanguage.org/

the project is structured poorly, i cannot find anything in that slop, i bail out, look it up yerself

>>26050
year 2026, retards still spur an incomprehensible file garbage into repos and call it projects..

>>26051
code diarrhea toilet

>>26048
>seethe and dilate tranny, hehehe
lol, being exposed as the retard you are really got you

>>26052
feeling when you kinda enter the place in hopes to check something and it is suddenly a..

> code diarrhea toilet

>>26052
>>26051
I'm sorry, I need to learn how to navigate a website, my HRT made me emotional

>>26049
lol
lmao even
wipe the shit off your hands before posting here SAAAAR

>>26048
> sorry am not a demagogue as yourself, i kinda need pragmatismus: yes - yes, no - no
You basically are confessing you are incapable of dealing with complex arguments. It's not like we hadn't already realized that

> then you know what was concluded
The conclusion was that you were a smooth brain namefaggot

>>26056
Nice retort.

desu I just got into this thread to confess that I'm a namefag who likes sucking cocks

>>26059
we know

>>26004
>Not if it's pure
are you really going to move the goalposts for the fact that methods are syntactic sugar for functions?

>>26055
>>26059
so what did you prove here? you think copying my name is a rigid impersonation? hehehe, nope tranny, you just proved the lack of your own identity. troons have this identity problem btw.

>>26057
>complex arguments

retarded statements, wespeaking nobody, they are retarded non-arguments.

--
IO started in 2002, yet unable to form a project structure to these days, 24 hecking years of nothingburger, finally slopified with AGENTS plis welp organize this mess.. pathetic. delete that diarrhea, press delete button - that will be the ultimate and final contribution

>>26048
>sorry am not a demagogue as yourself, i kinda need pragmatismus: yes - yes, no - no
Let me make it simple for you
- classes, types and objects are related but different concepts. you can have one of them without the other two

- you don't need to implement any kind of class concept in order to have objects, which was your thesis

- Types describe behavioral characteristics of a entity

- objects are entities with internal state and methods associated with it. They respond to messages


Class in common OOP language are use

-- class that defines a type
class Pizza {
int price;
void method() {};
}

-- object generation from a type defined by the class
p1 = new Pizza();
p2 = new Pizza()

(p1 is-a? Pizza && p2 is-a? Pizza) -- returns true

-- Class definition without a type (ignoring implicit inher and such)
class Pizza {};
p1 = new Pizza();
p2 = new Pizza();
(p1 is-a? Pizza && p2 is-a? Pizza) -- returns true because p1 and p2 are in a relation is-a with Pizza

-- Types without Classes (as in Haskell)
data Pizza = Raw PIzzaInfo | Cooked PizzaInfo;;

-- object without class and types. It's doesn't have any is-a? relationship
RawPizza = {
sauce := "red";
cook := method(
)
}

-- send a message to object pizza
RawPizza cook


The difference is pretty clear to me

>>26062
Stop pretending to be me

I am faggot and I loves cocks

i have some data, i want to transform that data, maybe send it over the network, dunno. where in that problem description does "let's colocate pieces of the transformation logic with pieces of the data so they can't see the whole picture, turning the whole thing into a tetris game of where-should-my-logic-live" enter the solution space? make subsystems, not objects, you retards

>>26063
Ignoring the crazy guy you're arguing with, and going back to the comment: >>26044
>classes were not a really the good concept it seemed in theory
It seems to me that "just an object, no class" is what most other people would call an "Anonymous Class." Thus, it's still a class in the sense of being explicitly hard-coupled data with methods, you just didn't have to name the class. It's almost as a closure in functional programming, where lambdas are commonly used but primarily for simple expressions and throwaway transformations.

As far as I can tell, the idea of an anonymous class is largely irrelevant to the big picture debates over the pros and cons of OOP. Indeed I would wager that most critics AND proponents of OOP would agree that if you're going to create method+property couplings, it's best to give these couplings explicit names most of the time. And when you don't name them, the language you're using is almost certainly just going to automatically generate a random class name for it under the hood anyway.

The debate about OOP is more about whether always (or by default) thinking in terms of tightly-coupled properties and methods is a good idea, along with frequent digressions on dynamic dispatch and the pros and cons of using vtables to implement object methods).

>>26063
by the way

RawPizza cook


Are you modifying the state of RawPizza to become a Cooked RawPizza?

RawPizza isCooked?
<returns true>


kek

>>26063
>>26064
>>26066

24 years.. still a nothingburger. how retarded one could be to fail to connect whatever "class" name to an object? PhD of retardation.

what is your containment chamber btw? LISP/dpt?

>>26066
>It seems to me that "just an object, no class" is what most other people would call an "Anonymous Class.
It seems like you are forcing the concept of class instead of just eliminate it in the equation. Just call the objects, which is what they really are

In real world classification can be a process to group/partition a population of already existing entities in order to then reason/make decision using the classification with the principle of substitution. In CS you start with an empty world and you do the opposite: generate population starting from a class so they belong to that class. The point is that the entities can exist without being classified

If every entity (objects in our case) has its own class it become a degenerate classification system and useless because every entity has a unique type. It would be like classifying humans by their complete genome sequence which would be useless so you don't do it

So, commonly, in programming language a class is a factory/generator of a type (and then object)

> Thus, it's still a class in the sense of being explicitly hard-coupled data with methods
That would be more akin to the definition of a type. But in alternative OOP implementation objects are entities that receive messages and either asnwer back or forward the message to other objects that are already instantiated in memory (ie: alive)
Semantically they are not hard-coupled with anything, they can receive a message that they don't know how to respond to (eg: missing method or attribute)

They are just objects, and every one has a unique identity

>>26069
>It seems like you are forcing the concept of class
No, I'm trying to eliminate semantic nitpicking as a source of argumentative digression.

>>26070
no,you are forcing the existence of a concept that doesn't make sense

Objects are objects, and they are not forced to "belong" to a class. Calling objects "anonimous class" is like saying every object (the entity that actually exist) is of the unique type defined by themselves that doesn't share its schema with no other object which is extremely dumb

is the "object" that has methods and attributes and blablabla. A class in common OOP implementation is a generator of objects that have the same schema

Also because objects can be dynamic


// What class does this object belongs to?
foo = {
height := 3
do-something =: method([...])
}

-- what about adding one attribute
foo width := 10
write(foo width) -- returns 10

-- What about method deletion?
foo delete(do-something)



Just say they are classless object and you'll be correct

>>26066
>As far as I can tell, the idea of an anonymous class is largely irrelevant to the big picture debates over the pros and cons of OOP.
As stated before they are objects and not anonymous classes
Then, from a theoretical standpoint, objects are an abstraction just as functions are, they have same the power description. So I do think the point of the discussion of OOP is actually a discussion about OOP implementations

> AND proponents of OOP would agree that if you're going to create method+property couplings
There are various way of thinking about this. For example, prototype OOP proponents (read Self guys and their moms) argue that a strong limitation of class based OOP implementation was the implicit coupling of traits (behaviour that act on instance representation) and its prototype representation. Respectively, the idea of mitigated by "abstract classes" and "<<class>> interfaces" and dataclasses. Then they continue arguing that you don't need extra-linguistic attributes (on top of not having classes) and you can directly use object + delegation and all the taxonomy emerges from the relation between objects and the separation or not of behaviour+representation inside an object
Another big problem is that in statically typed class-based OOP a receiver needs to know in advance at compile time the class it will receive and this lead to all the creational design pattern to work around this "limitation" and all the taxonomy of eg abstract factory for creation of family of objects that are unneeded in classless object systems

Prototype + dynamical objects also solves the "problem" of telescoping of constructors so no need an object builder for this specific problem. And they makes you able to write programs where objects have dynamical inheritance

These are just some examples of the consequences of different object model. There obviously downsides too but sitll is worth discussing if class based OO was the actually the best implementation

They're just collectively butthurt because someone who sucks aids at OOP spammed a meme into their brains.

>>26063
non-programming examples like this always lack any real program logic and just obfuscate the non-applicability of whatever the example is supposed to demonstrate

write code a real program could realistically contain

>>26065
once again, OOP doesn't couple data and logic as cniles continue to repeat like unresponsive retards
OOP couples state and logic. data is what the program processes at runtime

>where-should-my-logic-live
it's self-evident if you build your architecture around the logic
where/how is the data read? the data reader class
where/how is the data transformed? the data transformer class
where/how is the data sent over the network? the data sender class
and so on

>make subsystems, not objects
objects ARE subsystems

>>26074
I guess you didn't actually read what the comment was about

The comment was an attempt to show the difference between class, type and object. Since they are the primitive abstraction on top of which different programming language are build the snippets doesn't need to contain any programming logic, you just have to "instantiate" the abstraction

If you want to read about the difference you either read some document of theoretical difference or the first chapter of the corresponding languages
> strongly typed class-based OOP: Java
> duck typed class-based OOP: Python
> type-based language: Haskell
> (classless) prototype based OOP: Self, Io, XO

If instead you meant you wanted to see how to organize computation in prototype based language just look at the Morphic Self's UI toolkit or if you are lucky some piece of complex software written in classless era Javascript that's actually good

>>26074
>>26076
> If instead you meant you wanted to see how to organize computation in prototype based language just look at the Morphic Self's UI toolkit or if you are lucky some piece of complex software written in classless era Javascript that's actually good
Or, if your brain is able to generalize from ideas and notions, read the Self paper
https://bibliography.selflanguage.org/_static/organizing-programs.pdf

>>25886
Try to make a snake game in C++ with and without using OOP.

>Without OOP
Declare two structs in Main, food and snake, read input, move snake, draw cells, check if on tile with food. One file, 50 loc with Raylib.

>With OOP
Declare Main to manage the classes below.
Declare InputManager class with its own 'Update' function
Declare Food class with its own 'Update', 'Spawn' and 'Draw' functions.
Declare Snake class with its own 'Update', 'Draw', 'Move', 'ReadInput' functions, additionally, Snake needs access to InputManager.

Bonus points for creating an abstract 'GameObject' to unify Food and Snake's shared function names into a virtual function to make it clear what can be updated and what can't be updated.

>>25946
> encapsulation and abstract data types are OOP
This is the type of retard that promotes OOP. Just absolutely braindead.

>>26079
cry about it

I think they hate OOP because Java is verbose and C++ is ugly.

>>26076
comments that use animals or foods as "programming" examples should be immediately ignored

>The comment was an attempt to show the difference between class, type and object.
then show it on a real program and not some abstract non-programming example

>>25886
Maybe the whole is greater than the sum of its parts. Especially when the parts are so boring.

>>25924
>OOP does not solve the problem of making code more legible.
It lets you put a custom conceptual unit into places in your code where it helps with the data organization, and that LITERALLY makes the code more readable.
Using more abstractions fixes many problems, except for the problems that using more abstractions causes. Use carefully.

>>26082
> comments that use animals or foods as "programming" examples should be immediately ignored
That applies to 99% of the code you see, but this is not the case and I knew why you made that comment but I let you tell me

> then show it on a real program and not some abstract non-programming example
How the fuck could I show the grammar and semantics of a primitive of a language you retard?
Again, if you are interested in them profound and theoretical formalization of those concept you read a book about type systems or you read the chapter of the languages I listed you about their abstraction model

> then show it on a real program
I'm not taking an interview with you nigger, I wont write a "real program" on a cantonese imageboard. I already told you what you should look for finding **real programs**. Are you able to fucking read ?

> some abstract non-programming example
But the point is actually about the abstract differences of models