λ

>when bitch boy undergrads say stupid shit thinking it's deep
wew lad

>>53608663
>Wouldnt OO then be the best possible paradigm since it reflects our real world?
No. Because we're not all instance of human. Human is a generalization of us.

>>53608663
>call is 6x more common than ret
What the fuck?

>>53608663
Yes, that's the whole reason OO was invented.

Anyone who hates OO and argues against this is just too retarded to understand how or it works.

>>53608663
Categorizing things has nothing to do with OOP.

If you have data and functions (which are a special, functional, kind of data as well, actually), you can still categorize everything into functions and other data, and then further.

OOP is simply about the idea of attaching each of those functions to one type of data. This works nicely and is easy to understand, but the problem with it is that if a function has multiple parameters, it's not related to just one type of data, so attaching a function to the type of one of its parameters is kind of an arbitrary decision in the end. Coupling functions with some type of data causes some practical problems sometimes, especially when there really is no "dominant" type among the parameters.

Lastly, if you have an arm object, do you think moving it should be a function of the arm itself? That sounds intuitive, but in the end it's a stylistical choice. There could just as well be a free function to move the arm. Both approaches get the job done, but the latter highlights the top-level separation of function and other data values. In the real world the arm does move itself independently, but the process of moving can still be described as a function regardless of which entity is the source of the process. Does it even matter who moves the arm? We're not interested in that, and not trying to describe it. Even further, what if somebody else moves your arm? Now the OOP way of telling the arm to move itself is, in fact, conceptually wrong, while the "normal" way doesn't take a stand in the issue of who was the source of movement. So, in fact, coupling the process, the function, with the entity that it acts on, is technically wrong even if that object itself (usually or always) is the source of the effects of that function.

>>53609481
In a more complex case it's not even easy to tell with which type the function should be coupled: if you have a pen object and a canvas object, do you think the draw method should be part of the pen or the canvas? There's really no absolute answer.

Hey Matrixfags, how could we be living in a simulation if it would take an infinite computing power to PERFECTLY simulate one single boson?

Checkmate, atheists.

>>53609481
Lastly I should point out that categorizing things into regular data and functions indeed seems to be the "objectively correct" way as the arm example suggests. Everything you experience is either static data or ways the data can change (which is data too). Objects containing ways to act on themselves, on the other hand, is also a phenomenon of the real world, but not one that's interesting on programming, since programming is solely about achieving a desired result, in which context we're not interested in the extra "outside" information about the entity which is causing the results to happen - if there is an entity that takes part in the results of a function, by either supplying information or mutating, it is expressed as an explicit parameter to the function, just like all data the function uses, because that's the way functions work. Again referring to the arm example, attaching the ways the arm can change into the arm means that there should also be a function for every other entity that can perform the same transformation on the arm. But this is a pointless distinction since we were never interested in who performs the transformation, only about what the transformation leads into, and that's what functions directly describe. Data and functions to act them is all we need in programming context.

>>53609481
Well that was a wasted rant