The Repeated Deaths of OOP (2015)
121–130 of 220 posts
Re: The Repeated Deaths of OOP (2015)
#122Earlier quoted context omitted.
How are expressions not based on lambda calculus in most “ordinary” languages? Yeah, they may side effect but at the same time lambda calculus itself is untyped, so is Haskell all that much closer to it over C++?
Many other languages are not expression based at all. for loops cannot be considered "lambda calculus", for example (although of course there is a translation of them into a lambda calculus equivalent).
Re: The Repeated Deaths of OOP (2015)
#123Earlier quoted context omitted.
> The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. I've never found myself thinking that my pan fries an egg. I fry an egg and use the pan and the stove to do it. I've also not found myself thinking that my pan hits an intruder and dents itself. I hit the intruder (well, if I had the courage) and the resulting 'data/object' now has 'dent' as a…
On the other hand, when you make coffee you probably aren’t thinking about how to heat the water, measure the temperature, adjust the flow rate, etc. When you use the microwave you don’t think about cycling the magnetron to hit the power level appropriate for the settings or spin the turntable. When you drive a car, you accelerate, brake, steer, etc. without directly manipulating all of the parts & microcontrollers w…
From the perspective of Procedural Programming this also works well:
brew(coffeemaker), defrost(oven, "meat", "500g"), accelerate(car).
Same for FP:
brewed(grains), defrosted(meat, time), withAcceleration(car).
Re: The Repeated Deaths of OOP (2015)
#124Earlier quoted context omitted.
> If one says that ECS a just another design pattern, then it's only fair to say that OOP is also just a design pattern in itself, since I could implement OOP itself in C (see Linux Kernel), Haskell or ECS if I wanted. Well, it is? What do you mean by looping itself? How is having a struct dissimilar to having an object iterated, especially with C++ essentially having barely any difference between a struct and a clas…
> Well, it is? If you say so we can agree on that, yes. :) > What do you mean by looping itself? I mean that that ECS is not merely looping over an array like GP claimed. In production ECS, Systems normally act on more than one kind of Component, so "iterating over the array" of components is not feasible. Iterating over entities kinda kill the performance and data locality too, so you need something smart closer to…
Re: The Repeated Deaths of OOP (2015)
#125Earlier quoted context omitted.
ECS can also be implemented in functional or imperative languages, and it often is. The fact that ECS can be implemented in OOP languages doesn't make it an OOP pattern, only that OOP languages have Turing-completeness. You could also write Pure-FP code or implement Prolog in an OOP language, or vice-versa. > If you move the global functions to the entity objects themselves, you end up with OOP. You're probably talki…
Why do critics think looping over an array is somehow incomprehensible in OO and must be replaced with inheritance or something? Most ECS implementations are in OO languages. In Unity/C#, those systems are objects those arrays holding component information are even objects! Its really not a stretch for OOP. Its just a design pattern.
It is in keeping with the spirit of OOP to wrap up different entities' data in separate objects and have them interact with each other through methods. Exposing all of every entity's data to the world and letting unaligned actors unilaterally mutate many entities' state with no middle man is very un-OO, even if you dress it up in classes and methods.
Re: The Repeated Deaths of OOP (2015)
#126Earlier quoted context omitted.
> Well, it is? If you say so we can agree on that, yes. :) > What do you mean by looping itself? I mean that that ECS is not merely looping over an array like GP claimed. In production ECS, Systems normally act on more than one kind of Component, so "iterating over the array" of components is not feasible. Iterating over entities kinda kill the performance and data locality too, so you need something smart closer to…
Thanks for the details! Though wouldn’t using arrays of structs kill the performance the same way as array of objects do (stack-allocated ones)? So, one would essentially have to have a SOA, or — the OOP abstraction: a class of arrays that enclose this hot loop of code, making the implementation opaque to a calling code.
Not really. Components are long-lived so they're not allocated on the stack. And contiguous arrays of structs/objects is the best case for cache locality, that's the entire performance case of ECS.
Re: The Repeated Deaths of OOP (2015)
#127Classes were never definitional for OO, so prototypes, as originated in Self and adopted in JS, are not a violation of it. Function calls and messages are, fundamentally, isomorphic. Messages were never definitional. The notion of "purity", everything is an object, was never definitional. That was a Smalltalk conceit. Alan Kay named the idea, but stole it. So he doesn't get to impose his religion. What is definitiona…
The essence of OOP is not inheritance, that’s a nice to have. The essence of OOP is to encapsulate the data and the functions that operate on that data into an object and hide the internal state of the object from the rest of the program.
Re: The Repeated Deaths of OOP (2015)
#128Earlier quoted context omitted.
The essence of OOP is not inheritance, that’s a nice to have. The essence of OOP is to encapsulate the data and the functions that operate on that data into an object and hide the internal state of the object from the rest of the program.
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late binding of all things." – Alan Kay
EDIT: changed ancestor to descendant, thanks gnufx!
Re: The Repeated Deaths of OOP (2015)
#129Earlier quoted context omitted.
Why do you consider inheritance definitional? Is it definitional by de facto, or is there an authoritative definition that you are using? The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. But inheritance as adopted by most simula-derived languages does not exist in the real world. What does exist in the real world is prototypal inheritance (spec…
Where do we see prototypal inheritance in nature? I can think of lots of examples of composition, but none of prototypes. The closest I can think of would be DNA, but even that would be better modeled as composition in my mind.
However, if I believe that your assumptions about the event won't reify the event in a way that mirrors my own then I will want to override your assumption by communicating extra properties about the event. You can dive a bit into this by way of semantics.
For example, the semantic frame 'cooking'[1] lists 'fry' as a member. What are the salient differences between the parent frame 'cooking' and its member 'fry'? A quick way to explore this is by examining the propositional differences between the frame and member roles. You can imagine the differences between the Instrument and Result roles and how their assumptions differ.
How does this relate back to programming? One way to examine programming languages is through their ontological semantics. As much as we write programs for computers, we also write them for other people. Prototypical inheritance mirrors the structure of languages we already find in nature.
[1] https://verbs.colorado.edu/verb-index/vn3.3/vn/cooking-45.3....
Re: The Repeated Deaths of OOP (2015)
#130Earlier quoted context omitted.
He has been pretty clear in giving a lot of credit to the inventors of Simula, but that at the same his ideas derive more from Lisp. He even has a Quora answer where he explains that Lisp is the greatest language because he views it as a big shift in thinking. There is also a well known clear answer of his to the question of what is OOP to him. We ended up with something different in real life, but it's pretty silly…
On some people, Alan Kay's territorial claims to others' ideas leave a bad impression. Nobody begrudges him (with Dan Ingalls) Smalltalk, which represents a serious material improvement over Lisp syntax. But it looks like sour grapes to complain about C++, a language designed by a grad student of Kristen Nygaard that found success in industrial applications. Practical reasons for that success—independent programs tha…