Live data from Hacker News

The Repeated Deaths of OOP (2015)

loup-vaillant.fr

1–10 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#3
This is an opinion piece from 2015.

It goes without saying that there are no universal standard solutions. As an engineer, you learn how to proceed in a structured and systematic way and (hopefully) apply appropriate methods and technologies that fit the problem at hand. ECS is a good approach and there are many problems where this is a good fit; however, there are also problems where it is a less good fit. The same applies to OOP and all other methods of software engineering.

Re: The Repeated Deaths of OOP (2015)

#4
post #3

This is an opinion piece from 2015. It goes without saying that there are no universal standard solutions. As an engineer, you learn how to proceed in a structured and systematic way and (hopefully) apply appropriate methods and technologies that fit the problem at hand. ECS is a good approach and there are many problems where this is a good fit; however, there are also problems where it is a less good fit. The same…

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.

Re: The Repeated Deaths of OOP (2015)

#5
post #4
post #3

This is an opinion piece from 2015. It goes without saying that there are no universal standard solutions. As an engineer, you learn how to proceed in a structured and systematic way and (hopefully) apply appropriate methods and technologies that fit the problem at hand. ECS is a good approach and there are many problems where this is a good fit; however, there are also problems where it is a less good fit. The same…

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.

The article is primarily trying to suggest that "OOP" has "died" so many times that it should no longer be used. As if OOP was an ideology to be committed to or not.

Re: The Repeated Deaths of OOP (2015)

#7
post #4
post #3

This is an opinion piece from 2015. It goes without saying that there are no universal standard solutions. As an engineer, you learn how to proceed in a structured and systematic way and (hopefully) apply appropriate methods and technologies that fit the problem at hand. ECS is a good approach and there are many problems where this is a good fit; however, there are also problems where it is a less good fit. The same…

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.

It does a poor job of this in light of component based OOP approaches.

Re: The Repeated Deaths of OOP (2015)

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

Re: The Repeated Deaths of OOP (2015)

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

Re: The Repeated Deaths of OOP (2015)

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

Post reply on HN