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

111–120 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#111

Post by kaba0 »

flohofwoe wrote: post #52

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

First of all, OOP is most definitely not killed. Second, OOP is indeed (one of the idioms) what makes it possible to build complex software — even complex, pure C programs sort of do something OOP-like in the end.

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

And no, we didn’t use to write better code, it is only bias/we simply ignored most of the requirements, eg. ASCII-only, etc. Unfortunately most software products are not incentivized to be over the top stable so a few bugs here and there are “okay”. But that is an orthogonal problem.

Re: The Repeated Deaths of OOP (2015)

#112

Post by kaba0 »

andi999 wrote: post #88
Hermel wrote: 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.

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

How is it a flaw? There are data-first processes where a LISP-style data “objects” are better, but there are many stateful objects, eg. a database connection where you very much don’t want anyone to access a flag with this specific meaning or IP or secrets, etc.

Re: The Repeated Deaths of OOP (2015)

#113

Post by kaba0 »

teknopaul wrote: post #107
zepto wrote: post #87

Earlier quoted context omitted.

> 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?

Interesting question. Objects with functions that they perform seems to be a construct post technology. It's a good fit for a microwave but not for a door. It's a good fit for a person or anything with intelligence but arguably OO is _not_ a good fit for an object.

What about the weather, ant colony (which only has intelligence as an emergent feature at most), fire, a forest, etc?

Re: The Repeated Deaths of OOP (2015)

#114

Post by kaba0 »

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

> 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 class?

Re: The Repeated Deaths of OOP (2015)

#115

Post by kaba0 »

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

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++?

Re: The Repeated Deaths of OOP (2015)

#116

Post by ncmncm »

locallost wrote: post #65
ncmncm wrote: post #26

Earlier quoted context omitted.

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.

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 that run at native-machine speed, using native-machine data representations, and intimately compatible with an existing, successful industrial language—were chosen with careful deliberation, leaving certain Lisp strengths—particularly, function literals—aside, for later. It seemed like the right approach, at the time, and turned out to be.

Java could have been the practical Smalltalk, but its designers elected instead to ape superficial details of C++, for no defensible reasons, to Java's detriment.

The good ideas in Smalltalk have not had much effect on the world. All of Smalltalk's weaknesses were inherited directly from Lisp, leaving it with no better prospects than Lisp has had, or has, for identically the same reasons. But it turns out the "object orientation", like any other exclusive organizational principle, is an inadequate basis for a language meant for broad use. So, C++ supports OO and other styles, and even Java has begun to branch out.

Subsequent development of C++ has drawn mainly upon ML, fleshing out support for other organizational styles that Smalltalk and Lisp never attempted. And, it got lambdas, after all.

Re: The Repeated Deaths of OOP (2015)

#117

Post by kaba0 »

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…

Sorry, it’s my pet peeve, but referential transparency doesn’t mean what many think it does — what you mean is simply side-effect freeness.

See the top answer here: https://stackoverflow.com/questions/210835/what-is-referenti...

Re: The Repeated Deaths of OOP (2015)

#118

Post by tome »

kaba0 wrote: post #115
ebingdom wrote: post #35

Earlier quoted context omitted.

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.

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)

#119

Post by ratww »

kaba0 wrote: post #114
ratww wrote: post #110

Earlier quoted context omitted.

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

> 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 "materialised SQL views" to get performance.

> How is having a struct dissimilar to having an object iterated, especially with C++ essentially having barely any difference between a struct and a class?

I never said it was. I just said that merely using a "class" doesn't make something an OOP pattern, especially if the implementor has no choice over which programming feature to use.

Re: The Repeated Deaths of OOP (2015)

#120

Post by slver »

tome wrote: post #101
pflanze wrote: post #79

Earlier quoted context omitted.

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…

Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting. The operative point is that, in Haskell, firstly x = expression y = expression ... is the same as x = expression y = x ... and that, secondly x = expression ... is the same as ... when x does not appear in ... . Those are the important properties of Haskell (with regard to this discussion). Whether this advance…

I'm not deep into Haskell, but isn't the interpreter monad pattern effectively a language within the language that acts in a very conventional procedural way for interacting with IO and other external concerns? I just wonder... does Haskell really need syntactic segregation for this, and how is that better than any language which can declare/enforce pure functions/modules without the entire language being like that by default.
Post reply on HN