Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

41–50 of 357 posts

Re: OOP Is Dead, Long Live OOP

#41

OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. You can do most things with OOP or without OOP but each path has some upsides and downsides and most of the time it's good to use some things it provides where it ma…

> The great architect has the foresight on how the code will be used in five years and design it accordingly

Perhaps this is a function of me working in startups and consulting my whole career, but it seems extremely misguided, if not negligent for an experienced engineer trying to design for use cases five years in the future. Five months into the future is even pushing it.

What kind of companies operate in this way?

Re: OOP Is Dead, Long Live OOP

#42
post #27

Earlier quoted context omitted.

> OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. No... I think this is missing precisely what was exactly the point of the article (see "(B)" in the text). This post is not a fight over OOP religion. The point of…

Just because prior literature exists, does not mean it should not be superseded. For example, generics wasn't even a thing when OOP originally started and yet LINQ and basic list ADT's wouldn't be as powerful without it.

> For example, generics wasn't even a thing when OOP originally started

Generics werent part of the earliest OOP because generics only make sense with static typing and the earliest OOP languages were dynamically typed; generics were around other places around the time of early OOP, though.

Re: OOP Is Dead, Long Live OOP

#43
post #10

Earlier quoted context omitted.

I think this relates to what you're saying. I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). But when I'm using Java, as one example, it often feels like I'm really locking myself into a design up front. In Python, especially. I'll find myself starting off all experiments or simple projects with function…

But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. Sure, that limits creativity, but in many business contexts, the last thing you want is your programmers getting "cute". There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...

I'm glad I don't work places that try to keep me from being "cute".

Re: OOP Is Dead, Long Live OOP

#44

OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. You can do most things with OOP or without OOP but each path has some upsides and downsides and most of the time it's good to use some things it provides where it ma…

>The great architect has the foresight on how the code will be used in five years and design it accordingly. Isn't he better off taking that crystal ball that gives him the foresight, using it to pick the correct lottery numbers and simply retiring?

Many applications run maybe 10 times on real data and then their purpose is fulfilled. You don't need to design a microservice architecture with redundant servers when a simple shell script could do the job better.

You need to foresee the scale of what you're building and how you would proceed to the next level. Some things must be solved right before the first deployment because you can never change them after the application is deployed. You must know what these things are and solve them right. You must also reduce their number ideally to zero if possible. You must use solutions that allow refactoring and later scaling in areas where your crystal ball is not sure. If the hard things are solved correctly you can use average workers to do the rest and it will work well.

Re: OOP Is Dead, Long Live OOP

#45
post #20

I’d be very wary of hiring an ”OO” dev who can’t reasonably formulate what the SOLID principles are and why they exist.

Depends on what this dev would be building, if you have to build framework or you build a library then I agree. If you build next off the mill "business" system then...

Single responsibility principle, yes nice but we have deadlines and no time to argue if that one function should be somewhere else, fix it when we have some slack.

Open closed principle, you don't have to think about if you use DI and have interfaces.

Liskov substitution is useless, you should not use inheritance but composition.

Interface segregation, you have to think about it but it is a lot like SRP.

Dependency inversion, interfaces plus DI framework takes you far enough.

So IMO if one senior guy sets up project with DI framework and gives general direction, someone who can't formulate SOLID still can be good OOP developer.

Re: OOP Is Dead, Long Live OOP

#46
post #10

Earlier quoted context omitted.

But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. Sure, that limits creativity, but in many business contexts, the last thing you want is your programmers getting "cute". There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...

Yes. That may very well be. And I'm not saying Java is bad because of what I described. Just that I experience the, "ugh OOP isn't helping me do what I want to do here" with Java.

It probably is the right tool if you have an enterprise problem that needs an enterprise solution.

Re: OOP Is Dead, Long Live OOP

#47

OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. You can do most things with OOP or without OOP but each path has some upsides and downsides and most of the time it's good to use some things it provides where it ma…

> OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. No... I think this is missing precisely what was exactly the point of the article (see "(B)" in the text). This post is not a fight over OOP religion. The point of…

Just to add on to that.

Very few programmers know the prior art wrt. OOP, or have worked with the kind of code in which OOP is done well (I guess "OOD", using the terminology from the article). Instead, almost all junior (even senior) programmers I encounter parrot something along the lines of OOP being too enterpris-y and crufty, and something about inheritance being stupid. OOP is dismissed out of hand. It's high time for a correction in that mindset. The ability to structure your data and the operations on that data together in place is incredibly powerful, and OOP is a good approach to do that.

Schools are partly to blame. They teach OOP as if it is an exercise in abstracting some sort of reality (e.g. "a dog barks, a cat meows, and both walk"). But that approach falls apart for the sort of concepts programmers work with. OOP is at its core a way to structure code, and to do so cleanly, to avoid repetition, and to enable easy navigation through a program. It is not intended to be mental map of some external reality.

Re: OOP Is Dead, Long Live OOP

#48

I don't understand why this article is so angry? ECS is a great subset of OOP. Both are helpful tools where they make sense.

ECS as they are using it in this blog is about Data Oriented Design. It's not just OOP plus favoring composition over inheritance.

DOD explicitly advocates separating data from behavior, and is strongly opposed to OOP in general.

Re: OOP Is Dead, Long Live OOP

#49
post #10

Earlier quoted context omitted.

I think this relates to what you're saying. I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). But when I'm using Java, as one example, it often feels like I'm really locking myself into a design up front. In Python, especially. I'll find myself starting off all experiments or simple projects with function…

But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. Sure, that limits creativity, but in many business contexts, the last thing you want is your programmers getting "cute". There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...

> But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow.

That may have been where Java wanted to go, but, when I'm working in Java, I don't feel like that's where I am. Ways of doing things in Java tend to be wildly inconsistent from project to project. Partially, I think, because so much core functionality in the Java ecosystem was allowed to be federated out to 3rd-party projects for so long. Take the long-standing popularity (and rivalry) of Guava and Apache Commons for handling even basic tasks that are hard to get done using the core Java APIs. If there's such a thing as a "platform smell", I'd say that certainly qualifies.

With Python, on the other hand, there is a fairly consistent common understanding of what "Pythonic" means, and, even when there really is more than one way to do it, the question of which one to use can usually be quickly resolved to a predictable outcome by simply pointing out that one option is the more Pythonic way to do things.

(edit: Though, to be fair, Java was first released into a world where languages like C, C++ and Common Lisp represented the status quo. Expectations were lower at the time.)

Post reply on HN