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

51–60 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#51

Post by Rochus »

ebingdom wrote: post #45
Rochus wrote: post #39

Earlier quoted context omitted.

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

> Isn't every existing programming language eventually based on (or at least traceable to) lambda calculus? Not really. FP has an obvious connection to lambda calculus. Many OOP languages don't even have a straightforward notion of "function", which is what lambda calculus is all about.

Did you have a look at e.g. https://www.amazon.com/Theory-Objects-Monographs-Computer-Sc...?

Re: The Repeated Deaths of OOP (2015)

#52

Post by flohofwoe »

IMHO what actually killed OOP was the attempted industrialization of software development driven mainly by "Enterprise Java" (and similar failed ideas like UML). The promise was that with OOP it's possible to build complex software projects with cheap "unskilled labor", because OOP would provide the "framework" for managing complexity by plugging together very simple parts.

Two decades later we're still trying to clean up the resulting mess, but I think all in all we're on the right trajectory since around 2010.

Re: The Repeated Deaths of OOP (2015)

#53

Post by cout »

slver wrote: post #28
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…

> Classes were never definitional for OO, so prototypes, as originated in Self and adopted in JS, are not a violation of it. If we put classes and prototypes in stark opposition, we can say yes, classes are not foundational. But what's the main distinction between classes and prototypes? One is defined statically and other dynamically. Static/dynamic distinction is a matter of optimization, it's not fundamental to th…

I like the use of the word "mold" here; I've not heard it applied to programming before. Manufactured objects are often very different from the prototype, but it's harder to differ substantially from the mold.

Re: The Repeated Deaths of OOP (2015)

#54

Post by valenterry »

slver wrote: post #23
valenterry wrote: post #8

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 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 is a good example of why FP is much clearer defined. Referential transparency implies immutability. So there is no pure FP code that uses mutability.

> Some claim it's a style in any language, others that it's a type of language.

It's neither. It is a property of a program. Some languages enforce this property, others make it impossible to write a full program in this style. But that's independent of the definition itself.

I hope that explanation sheds a bit of light into it.

Re: The Repeated Deaths of OOP (2015)

#55

Post by vbsteven »

dragonwriter wrote: post #18
ehnto wrote: post #15

Earlier quoted context omitted.

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. MVCs original use was GUIs, which are not “single run applications with a discrete output”, but instead “software with a perpetual state and loop”. Yes, its since been adapted to web use, which usually fits that single-run description, but still...

Single run VS state+loop is not the best description of the distinction between MVC and ECS. I look at it like this:

In MVC a typical interaction goes like this:

    -> INPUT: user interacts with view
    -> view triggers controller action
    -> controller updates the model
    -> controller passes model to view
    -> OUTPUT: view changes
    -> (rinse and repeat)
The important part here is that there is a single input that flows through the steps and generates output. This maps well to web frameworks where the input is an HTTP Request and the output is the Response. It also maps well to GUI frameworks where the input is a user interaction event and the output is changes to UI on screen. The perpetual "state and loop" for triggering the next input from the previous output is implementation detail and doesn't really matter for the pattern.

ECS is different because it doesn't have discrete interactions converting input->output. Instead they are built up out of a number of systems all interacting with eachother. User inputs enter a system and that triggers a complex flow of other system interactions, eventually generating 0..N outputs.

Disclaimer: I have lots of experience using MVC in various domains, not that much with ECS.

Re: The Repeated Deaths of OOP (2015)

#56

Post by cout »

samsquire wrote: post #47

ECS is often implemented in an OOP language. I know of no ECS languages. You have objects that you iterate over and apply changes to the struct or object's fields like x and y coordinates in a game tick for the "next state" Essentially you end up with lots of global functions and very large API space that has no ordering. There's inherent ordering to global function application to produce the correct result. So it pr…

What would an ECS language look like? Would it differ substantially from an OO language?

ECS seems to me more like a pattern than a paradigm.

Re: The Repeated Deaths of OOP (2015)

#57

Post by valenterry »

jtdev wrote: post #49
ebingdom wrote: post #43

Earlier quoted context omitted.

> FP is a cult. It's a programming paradigm based on simple, well-understood mathematical framework. It's also the starting point for most research in programming language theory.

Explain why closures are allowed to mutate state in this “simple, well understood” framework.

They are not allowed to. Why do you think they are?

Re: The Repeated Deaths of OOP (2015)

#58

Post by valenterry »

Rochus wrote: post #10
valenterry wrote: post #8

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?

Yes, please see my other answer - it is much stricter/clearer defined than any OOP definition that I've seen.

Re: The Repeated Deaths of OOP (2015)

#59

Post by ebingdom »

Rochus wrote: post #51
ebingdom wrote: post #45

Earlier quoted context omitted.

> Isn't every existing programming language eventually based on (or at least traceable to) lambda calculus? Not really. FP has an obvious connection to lambda calculus. Many OOP languages don't even have a straightforward notion of "function", which is what lambda calculus is all about.

Did you have a look at e.g. https://www.amazon.com/Theory-Objects-Monographs-Computer-Sc... ?

Yes, that's one of the most prominent in a long line of attempts at creating formal models of OOP. And in the preface, you'll find:

> There is a well-established theory of functions, the λ-calculus, ... However, our theory of objects is self-contained; it is the first that does not require explicit reference to functions or procedures.

So that answers your question in the negative and proves my point: no, not every language is based on lambda calculus.

Re: The Repeated Deaths of OOP (2015)

#60

Post by ebingdom »

ebingdom wrote: post #37
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.

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.
Post reply on HN