The Repeated Deaths of OOP (2015) • Hacker News Board

Re: The Repeated Deaths of OOP (2015)

#81

Post by [deleted] » Sun, Jun 06, 2021, 3:13 PM UTC

pflanze wrote: post #79

valenterry wrote: post #72

Earlier quoted context omitted.

> Most real-world programming requires handling of side effects somewhere, so such programs have parts which are not referentially transparent. That's not correct though. Look at Haskell (or even stricter Idris). This is real world application code that can do whatever Java, C++, ... can do, but it is pure functional and hence doesn't contain any non referentially transparent parts. Just because an application is wri…

It's funny that you defend your view using Haskell, as I was replying with Haskell in mind. If you use the state monad, you encode local side effects. Then you use runState in a function that has a non-monadic type--a pure function. Feel free to argue that the state monad is only having pure expressions because it can be represented using only pure functions and partial evaluation. For all practical purposes it is us…

[deleted]

Re: The Repeated Deaths of OOP (2015)

#82

Post by slver » Sun, Jun 06, 2021, 3:34 PM UTC

valenterry wrote: post #54

slver wrote: post #23

Earlier quoted context omitted.

The funny thing is it's exactly the same thing with functional languages, and no, there's no clear definition of FP. Some FP is lazy, some isn't. Some is immutable, some isn't. Some claim it's a style in any language, others that it's a type of language.

FP means that every expression (= part that can be evaluated) is referential transparent. Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional") > Some FP is lazy, some isn't. The definition of FP implies that laziness is irrelevant. A language can enforce a pure functional style without being lazy or not. > Some is immutable, some isn't That's wrong. And it…

> > Some is immutable, some isn't

> That's wrong. And it is a good example of why FP is much clearer defined.

OCaml and F# are two examples of functional languages with freely supported mutable data types. So maybe what I said is "wrong" about your personal idea of what FP is.

But it's clearly not "wrong" about the fact some people see immutability as optional for FP, which is the very point I'm making.

Re: The Repeated Deaths of OOP (2015)

#83

Post by lolinder » Sun, Jun 06, 2021, 3:35 PM UTC

zozbot234 wrote: post #41

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…

Inheritance is definitional of OO as opposed to a simpler "object-based" paradigm.

Do you have a citation for "object-based" as a separate paradigm? The oldest reference I can find to that term is in the C2 Wiki, where it describes not a paradigm, but a pattern for approximating OO (including inheritance) in a procedural language without OO features[0]:

> Programming using [abstract data types] is also known as object-based programming. Even though ADTs do not directly support inheritance and polymorphism, these concepts can be layered on top of a ADT implementation with some minor effort. In other words all important OOP concepts can be implemented in OBP.

[0] https://wiki.c2.com/?WhyObjectBasedProgramming

Re: The Repeated Deaths of OOP (2015)

#84

Post by barrkel » Sun, Jun 06, 2021, 3:39 PM UTC

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.

I would say that polymorphism open to extension is also important, and subtype / supertype hierarchy. It implies some kind of composition of interface types in a static language.

Re: The Repeated Deaths of OOP (2015)

#85

Post by lolinder » Sun, Jun 06, 2021, 3:43 PM UTC

cout wrote: post #36

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…

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.

Re: The Repeated Deaths of OOP (2015)

#86

Post by ratww » Sun, Jun 06, 2021, 3:48 PM UTC

ehnto wrote: post #27

yakubin wrote: post #4

Earlier quoted context omitted.

The article doesn't argue that ECS is a good fit for everything. It argues that it is a better fit than OOP for some of the things OOP was intended for. And that it's a broader theme, where OOP is usually not the right tool for the job, even when it was originally intended to solve that particular job.

I'm confused. ECS is a type of OOP, is it not? An entity is an object in the same way a model is an object.

Not really. An "Entity" in most modern ECS implementations is normally implemented as an integer, which is used as a handle to which multiple components refer to.

A "Component" is normally implemented as a struct, and a "System" as a standalone function. No encapsulation here.

Of course you would have to implement all of the above using classes and objects if your language doesn't have support for structs or standalone functions, but that's just an implementation detail. The concept itself is not a subset of OOP, and breaks many "rules" of OOP.

Re: The Repeated Deaths of OOP (2015)

#87

Post by zepto » Sun, Jun 06, 2021, 3:54 PM UTC

cout wrote: post #36

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…

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?

Re: The Repeated Deaths of OOP (2015)

#88

Post by andi999 » Sun, Jun 06, 2021, 3:55 PM UTC

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.

While data encapsulation sounds like a nice feature in theory, it seems to be the actual biggest flaw.

Re: The Repeated Deaths of OOP (2015)

#89

Post by throwaway894345 » Sun, Jun 06, 2021, 3:55 PM UTC

kstenerud wrote: post #77

throwaway894345 wrote: post #42

Earlier quoted context omitted.

> Once you start arguing "OOP" vs xyz or "FP" vs xyz, you've missed the point. I think if we were intellectually honest in our arguments this would be fine—we could manage that OOP is poorly defined. Instead almost every debate about OOP takes this form: someone criticizes things which are exclusive to OOP (e.g., inheritance) or very common in OOP (kingdom of nouns, everything having references to everything else i.e…

> or they could give their definition of OO up front. This is exactly what they must NOT do. If one is going to criticize, criticize the actual bad concepts, not the (poorly defined) paradigm. OOP and FP are effectively undefinable, and rightly so since they have outlived their usefulness as vehicles for introducing their respective "bunch of concepts". Nobody's going to agree in the modern era what OOP or FP encompa…

> This is exactly what they must NOT do. If one is going to criticize, criticize the actual bad concepts, not the (poorly defined) paradigm. OOP and FP are effectively undefinable, and rightly so since they have outlived their usefulness as vehicles for introducing their respective "bunch of concepts".

It’s perfectly fine to define a shorthand for a larger concept, (even if that word has meanings in other contexts) so long as it’s clear what we mean by the term. We do this all the time in our writing and oratory (e.g., the biology sense of “immortality”).

The problem with OOP (and to a lesser extent, FP) is that we don’t make it clear what we mean by those terms and that makes for more misunderstandings between good faith actors and it gives bad faith actors more opportunity to drive the debate toward semantics. Being explicit up front solves that.

> Nobody's going to agree in the modern era what OOP or FP encompass, and anyone who attempts to define them will rightly be lambasted for it.

We don’t need to agree. We are free to define our terms. If I define OOP as X and criticize it accordingly, and you say “but my definition of OOP is Y so your argument is invalid!” then you’re very poor at reasoning and for all intents and purposes you’ve lost the debate.

Re: The Repeated Deaths of OOP (2015)

#90

Post by slver » Sun, Jun 06, 2021, 3:57 PM UTC

ebingdom wrote: post #60

ebingdom wrote: post #37

Earlier quoted context omitted.

It's true that functional programming also doesn't have a formal definition, but I wouldn't say it's "exactly the same" as with OOP. Functional programming is based on a simple well-understood mathematical model: lambda calculus. While there are different flavors of lambda calculus, they are related in obvious ways and one can reach formal conclusions them as a whole, e.g., the Church-Rosser theorem. In contrast, the…

To all the people downvoting me: if you really think OOP is as well understood as FP, learn some programming language theory. Tell me what the universally agreed foundation of OOP is. You won't be able to, but I can tell for FP it's lambda calculus.

> Tell me what the universally agreed foundation of OOP is.

I'll deliberately avoid terms so we don't get to argue about words, but rather substance.

1. Objects have identity that's independent of their state (two objects with same state are still distinct).

2. Objects contain implementation which is hidden, including optionally mutable state.

3. Communication occurs through handlers/methods/calls, which provide only INDIRECT access to the object's internal state.

4. Objects can stand for one another, if their handlers react in a compatible way with the object they're replacing.

I tried to keep it as basic as possible, while avoiding topics about inheritance and what not.

Now the question is "do you need an OOP language to do OOP", and no, you don't. There's overlap. For example if you take the above, you'll notice that closures in FP match all of those except one thing: mutable state. So if your FP language allows mutable state, then you can do OOP in it with closures. And that's not a proof that OOP is not a thing, rather it's a proof that what some small minds keep putting in opposition, things like FP vs OOP vs DOP are just pieces of a larger puzzle that forms a single cohesive picture.