Live data from Hacker News

The Repeated Deaths of OOP (2015)

loup-vaillant.fr

31–40 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#31
post #26
post #20

Earlier quoted context omitted.

> Alan Kay named the idea, but stole it. So he doesn't get to impose his religion. Bit rich to say he "stole it" when he himself said it's just the foundational principle around which systems form (living or not). Which already implies he doesn't claim to have invented it.

Somebody else invented it. Kristen Nygaard , in particular. He identified the three elements. It is common, when you steal an invention, to insist it is wholly natural , so not really any sort of invention at all. Saying it does not make it true. There was a time before; Kay came after.

Kay is said to have coined the term "object-oriented", but his conception of object orientation differs considerably from that of Dahl and Nygaard as well as from all current OO languages. Dahl and Nygaard invented the first object-oriented programming language (Simula 67) but didn't use the term. And yes, active objects reacting to messages (events) passed to them were already part of Simula I (1962).

The referenced article - like many others - moreover quotes Kay incompletely; Kay in the sentence next to the one quoted in the article said "the important thing here is that I have many of the same feelings about Smalltalk"; see https://www.youtube.com/watch?v=oKg1hTOQXoY&t=633s. Smalltalk-76 and 80 (in contrast to Smalltalk-72) implement inheritance and virtual methods as it was done in Simula 67, just like C++ and Java do.

Re: The Repeated Deaths of OOP (2015)

#32
post #16
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.

Every OO proponent seems to have their own definition of OO. Another I’ve heard is “message passing”, although that one even has many different flavors since it isn’t well defined and some argue that methods constitute message passing and others envision something closer to an Actor model.

This is all well and good as long as people are clear about what their definition is (although it is weird how many proponents have wildly different definitions and yet still seem to feel some kind of kinship). The maddening folks are those who deflect all criticism of OOP by saying “that’s not true OOP without ever asserting any particular definitional qualities. These people seem to have an undying love for the sequence of letters O-O-P. So we have these weird conversations where I say, “fine, I contend that anything that might make OOP unique from other paradigms (e.g., inheritance) is a misfeature”.

Re: The Repeated Deaths of OOP (2015)

#33
post #15
post #9

> Enough with the ECS advocacy however. Entity/component/system sounds like model/view/controller. But I like to think of data/logic/presentation. The point being that keeping these dimensions orthogonal is more imoprtant than how they are labeled.

They are quite different concepts and certainly in practice. At it's barest, a controller organizes models and renders them into a view. Again simplifying, an entity has components which describe it's functionality, and the entity can get passed through a system. The entity is the concept of the thing, and the components are it's features. The system uses the features to make decisions about how the entity interacts…

>I've never seen MVC used in anything but single-run applications that end with an discrete output.

Wut? Every desktop GUI framework in widespread use is some variant of MVC (i.e. MVC, MVVM, MVP, whatever…).

Re: The Repeated Deaths of OOP (2015)

#34
post #23

The article clearly shows that using the term OOP without further explanation is not helpful at all, rather confusing, because everyone has a different understanding. Compare that the "functional programming" which in comparison has a glas clear definition, which makes it much easier to decide if some program is "pure functional" or not, avoiding prolonged and unproductive discussions.

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 is a cult.

Re: The Repeated Deaths of OOP (2015)

#35
post #10

The article clearly shows that using the term OOP without further explanation is not helpful at all, rather confusing, because everyone has a different understanding. Compare that the "functional programming" which in comparison has a glas clear definition, which makes it much easier to decide if some program is "pure functional" or not, avoiding prolonged and unproductive discussions.

> "functional programming" which in comparison has a glas clear definition Does it?

I would say it doesn't have a formal 100% unambiguous definition, but it's certainly _more_ well-defined than OOP: a functional programming language is one which is based on lambda calculus.

Re: The Repeated Deaths of OOP (2015)

#36
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 (specifically through cloning, not through sharing a reference to the prototype object as we see in many Self-derived languages). We see it all over biology, manufacturing, even cooking. Is a language in which cloning a structure is the primary way of achieving inheritance still OO?

Re: The Repeated Deaths of OOP (2015)

#37
post #23

The article clearly shows that using the term OOP without further explanation is not helpful at all, rather confusing, because everyone has a different understanding. Compare that the "functional programming" which in comparison has a glas clear definition, which makes it much easier to decide if some program is "pure functional" or not, avoiding prolonged and unproductive discussions.

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.

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 many attempts to formalize the essence of OOP have resulted in countless wildly different results, so it's impossible to say anything meaningful about OOP, with the possible exception of this sentence.

Re: The Repeated Deaths of OOP (2015)

#38
post #16

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

Every OO proponent seems to have their own definition of OO. Another I’ve heard is “message passing”, although that one even has many different flavors since it isn’t well defined and some argue that methods constitute message passing and others envision something closer to an Actor model. This is all well and good as long as people are clear about what their definition is (although it is weird how many proponents ha…

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.

Re: The Repeated Deaths of OOP (2015)

#39
post #10

Earlier quoted context omitted.

> "functional programming" which in comparison has a glas clear definition Does it?

I would say it doesn't have a formal 100% unambiguous definition, but it's certainly _more_ well-defined than OOP: a functional programming language is one which is based on lambda calculus.

Isn't every existing programming language eventually based on (or at least traceable to) lambda calculus? OOP is just another way to organize code.

Human language is unsuitable for "glass clear", unambiguous definitions, just because of its inherent fuzziness (which is nota bene an essential property for efficient communication).

Re: The Repeated Deaths of OOP (2015)

#40
post #23

The article clearly shows that using the term OOP without further explanation is not helpful at all, rather confusing, because everyone has a different understanding. Compare that the "functional programming" which in comparison has a glas clear definition, which makes it much easier to decide if some program is "pure functional" or not, avoiding prolonged and unproductive discussions.

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.

AFAICT the core of FP is referential transparency. The "meat" of FP are the tools available which allow to (comfortably) increase the portion of the program that is referentially transparent.

Immutability, first class functions, laziness are all such tools. And which tools are used can vary, just like the tools that help "doing OO" can vary.

But I think that FP does have that core which has a glass clear definition. I'm not sure which is the core of OO. Maybe it's the idea of "encapsulating" mutation (basically inverting the core of FP). Maybe it's the principle of virtual methods / messaging. It's not so clear I think.

Post reply on HN