Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Repeated Deaths of OOP (2015)

loup-vaillant.fr

Post reply on HN
Print view View original

161–170 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#161

Post by augustk »

Hermel wrote: post #16
ncmncm wrote: post #13

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

What you describe is the essence of an abstract data type (ATD). An ADT can be easily implemented in a non-object oriented language like C. To my understanding the essence of object oriented programming is inheritance and polymorphism.

Re: The Repeated Deaths of OOP (2015)

#162

Post by ProfHewitt »

Rochus wrote: post #48
cout wrote: post #38

Earlier quoted context omitted.

The concept of a message is older than the actor model, so I don't think it can be considered a fundamental part of the definition of a message (so Smalltalk-style messages are still messages). I do think the Actor model is the most ideal form of message-passing in a single-process system, and seems to be the direction many languages are heading toward as they evolve.

> The concept of a message is older than the actor model Publications by Hewitt or Sussman in the seventies even suggest that the concept traces back to lambda calculus. > so Smalltalk-style messages are still messages Only Smalltalk-72 had true "message passing" (i.e. arbitrary tokens sent to an object for interpretation); Smalltalk-76 onwards uses a virtual methods implementation similar to the one of Simula 67 or…

The tokens in Smalltalk-72 were not "messages" to Actors where whole messages are Actors.

Since Actors are universal primitives of digital computation,

it is possible to reframe all previous work as using

messages, including Turing Machines and the lambda calculus.

Lambda calculus was originally defined using string substitution.

Both lambda calculus and Turing machines are computationally less powerful than Actors.

Re: The Repeated Deaths of OOP (2015)

#163

Post by jayd16 »

bccdee wrote: post #125
jayd16 wrote: post #104

Earlier quoted context omitted.

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.

Being written in an object-oriented language doesn't make code object-oriented. I could write Java using classes as (namespaces for stateless functions) XOR (structs with no methods), and while it'd still technically all be objects and methods, in practice it wouldn't embody the spirit of OOP at all. It is in keeping with the spirit of OOP to wrap up different entities' data in separate objects and have them interact…

>Exposing all of every entity's data to the world and letting unaligned actors unilaterally mutate many entities' state

But that is NOT the pattern. Entities are ids, they have component tags that opt entities into some functionality and the systems encapsulate and track the mutable state that system controls.

If you want to start sharing ownership of mutable state, that basically comes down to an implementation detail. Unity's ECS system does NOT let "unaligned actors unilaterally mutate many entities' state with no middle man." One could perhaps implement it that way if they so choose. It's just a matter of taste because, again, the design pattern is not inherently OO or non-OO.

Re: The Repeated Deaths of OOP (2015)

#164

Post by mypalmike »

ratww wrote: post #128
mariodiana wrote: post #108

Earlier quoted context omitted.

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late binding of all things." – Alan Kay

That's a great definition, but it mostly applies only to Smalltalk itself and a subset of Smalltalk descendants, like Ruby. EDIT: changed ancestor to descendant, thanks gnufx!

I'd say most of these attributes map pretty well to modern OO practices in popular languages, particularly Java, where late binding comes from widely used inversion of control frameworks like Spring. And the underlying mechanism for these is dynamic method dispatch, which I'd agree with Robert Martin is the single unifying requirement of OO.

Re: The Repeated Deaths of OOP (2015)

#165

Post by cout »

zepto wrote: post #87
cout wrote: post #36

Earlier 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…

> is because it mirrors how many people naturally think about the real world I’ve seen this said, but never justified. Is there anything that supports it?

To clarify, I don't think OO is natural for all problems, and I don't think it is natural for all people either. But for many people, it is natural.

Do you describe the world around you using nouns? Anything you can name is an object. When you hear me use the word "pencil" you know I am describing something that's used for writing on paper, containing a substance like graphite that is probably erasable, and maybe even has its own little eraser on the end. Naming the object allows us to communicate and reason about it together; the ability to name and classify objects is the most essential element of OO (imagine a language where you can create classes but not name them; would it still be OO? I would argue it is not).

Of course this is not the only way to model the world. Maybe to you the act of writing or drawing is more important; the pencil or pen or marker is secondary. Or maybe the connections between objects is important to you. Or perhaps it is not the objects that are important (i.e. those things which are acted upon) but the subjects (those things which act). Whatever model feels most natural to you is probably valid. As the saying goes, "all models are wrong but some are useful"; this applies to the OO model as much as any other.

Re: The Repeated Deaths of OOP (2015)

#166

Post by Rochus »

ProfHewitt wrote: post #157
nailer wrote: post #2

As the article mentioned the meaning of OOP changed over time. Alan Kay has a description of OOP that sounds like the actor model used in erlang/elixir or mq and consuming services elsewhere.

Smalltalk evolved over time. Is Smalltalk in 1972 an OOP programming language?

Probably yes, if you ask Dr. Kay, probably rather no, if you ask other programming language authors. It e.g. lacks inheritance and some other OO features present e.g. in Smalltalk-80. But I guess the question was rethorical anyway.

Re: The Repeated Deaths of OOP (2015)

#167

Post by mypalmike »

c-cube wrote: post #156
jcelerier wrote: post #68

Earlier quoted context omitted.

ML modules are definitely OO

See, that's just ridiculous and shows how undefined and vague "OO" is. The only relevant feature there is encapsulation, that most languages provide in some way. How is that OO? I vote for just not using this term anymore and talk about class based langusges or prototype languages or whatever.

The problem isn't that the term is poorly defined. It's that it's widely misused. Dynamic dispatch (basically "inheritance") is what most experts claim to be the defining feature necessary to claim OO.

Re: The Repeated Deaths of OOP (2015)

#168

Post by cout »

lolinder wrote: post #85
cout wrote: post #36

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

Mitosis is the cellular equivalent of prototypal inheritance; the cell clones itself, and then you have two cells, each a copy of the original.

You even get an inheritance hierarchy when pluripotent cells divide and become differentiated; the new cell gains functionality missing from the original as genes are turned on.

And yes, there's lots of composition too -- a cell is composed of cytoplasm, organelles, and a membrane (which serves as an interface to the message bus, your blood). The mechanism by which the cells are copied does involve DNA, but it and the proteins involved are an implementation detail.

Re: The Repeated Deaths of OOP (2015)

#169

Post by jayd16 »

ratww wrote: post #110
jayd16 wrote: post #104

Earlier quoted context omitted.

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.

ECS is doing a bit more than looping over arrays, though. In modern production ECS systems there's often the case where a System acts over two or more Components is very common, and looping itself is not good enough for those cases (because you get O(n^2) , O(n^3) , O(n^4) , etc, etc complexity), so it's nowhere near as simple as that. Like I said, it's possible to implement anything that is computable in any Turing-…

> System acts over two or more Components is very common, and looping itself is not good enough for those cases (because you get O(n^2), O(n^3), O(n^4), etc, etc complexity), so it's nowhere near as simple as that.

Am I missing something? Sort your data structure and quickly loop over them? Why would you ever do things at n^4 complexity?

> then it's only fair to say that OOP is also just a design pattern

Yup. It is. No reason to treat it like a religion throw it away because you can't force

Re: The Repeated Deaths of OOP (2015)

#170

Post by cout »

bob1029 wrote: post #94

In my experience, OOP works great until you run into a problem domain with circularly-dependent types that actually make sense as such to the business. Certainly, there are ways to manage this within the realm of OOP, but I strongly argue that these solutions are half-assed at best. Also, nesting of complex types (i.e. making assumptions about the shape of the domain model) also seems to be a large part of what cause…

Even the most fundamental types in smalltalk derivatives are circularly defined (using Ruby as an example: Object is an instance of Class, and Class inherits from Object). Circularity doesn't make this any less useful as a model, just more difficult to reason about. It's a tradeoff.
Post reply on HN