The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#41

Post by tgflynn » Fri, Jul 31, 2020, 2:52 PM UTC

lgessler wrote: post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

So what is your preferred solution for programs that intrinsically need to deal with a lot of state ? Global variables ?

I used to see that type of approach in some complex Fortran simulation programs where every function referenced a huge common block. I really don't think that leads to easier to manage solutions.

Re: The Case Against OOP Is Wildly Overstated

#42

Post by dionian » Fri, Jul 31, 2020, 2:53 PM UTC

clktmr wrote: post #27

> The solution to the fragile base class problem and other inheritance hangovers is surprisingly simple — don’t use it If OOP provides the footgun to shoot yourself, OOP is at fault. Overall the article reads as "OOP has no problems if is used correctly". Of course that's true. I have seen well designed OOP programs, but the majority was not. The author should ask the question, why OOP is applied the wrong way so oft…

With more power comes more need for discipline.

Re: The Case Against OOP Is Wildly Overstated

#43

Post by dionian » Fri, Jul 31, 2020, 2:54 PM UTC

lgessler wrote: post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

I don't see why the Law of Demeter cannot be adhered to in OOP. I do it every day.

Re: The Case Against OOP Is Wildly Overstated

#44

Post by TOGoS » Fri, Jul 31, 2020, 2:54 PM UTC

michaelcampbell wrote: post #11

mimixco wrote: post #5

Earlier quoted context omitted.

Agreed. The biggest problem with OOPS lies in its original premise: that code and data should be the same thing! This is grevious error, IMHO, that leads to nothing but problems: endless boilerplate code, lots of "interfaces" that essentially do nothing (that couldn't be done directly with said data), and debugging nightmares. I much prefer to work with systems where code and data are separate and never the twain sha…

OOPs original premise is homoiconicity? Really?

I'm pretty sure what was meant by 'code is data' is that a lot of OOP training encourages you to "bundle the code and the data in an object". People take that to heart, and...bundle code and data into objects. Whether or not those functions and that data really belong in the same object is an afterthought, if considered at all.

Re: The Case Against OOP Is Wildly Overstated

#45

Post by dionian » Fri, Jul 31, 2020, 2:55 PM UTC

skrtskrt wrote: post #8

The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs) As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense. It also encourages to people to blur or ju…

But that is the tradeoff of ORMs. Black box with free stuff but more complexity. Sometimes (usually?) it does not make sense to use them.

Re: The Case Against OOP Is Wildly Overstated

#46

Post by winstonewert » Fri, Jul 31, 2020, 2:55 PM UTC

michaelcampbell wrote: post #11

mimixco wrote: post #5

Earlier quoted context omitted.

Agreed. The biggest problem with OOPS lies in its original premise: that code and data should be the same thing! This is grevious error, IMHO, that leads to nothing but problems: endless boilerplate code, lots of "interfaces" that essentially do nothing (that couldn't be done directly with said data), and debugging nightmares. I much prefer to work with systems where code and data are separate and never the twain sha…

OOPs original premise is homoiconicity? Really?

I presume "code and data are really the same thing" is intended to refer to way that OOP binds code and data together.

Re: The Case Against OOP Is Wildly Overstated

#47

Post by liability » Fri, Jul 31, 2020, 2:58 PM UTC

xtian wrote: post #24

bussierem wrote: post #17

Earlier quoted context omitted.

I think it's telling that I'm not able to tell whether you're talking about OOP or FP in this comment.

Is there controversy about what FP “actually means”?

The only real contention seems to be whether "functional programming language" should describe languages that merely facilitate functional programming (e.g. lisp), or only to those that enforce it (Haskell.)

Otherwise, whether or not a procedure is a function is about as clear cut as you can get. It either is or it isn't, it's not subjective.

Re: The Case Against OOP Is Wildly Overstated

#48

Post by api » Fri, Jul 31, 2020, 2:59 PM UTC

grugagag wrote: post #14

api wrote: post #3

Earlier quoted context omitted.

That sounds snarky. Not sure if that was intended or not, but regardless I read your comment as: "OOP is good when you use the object oriented structure as a tool to organize your code and data to solve a problem, but not when you try to wrap your solution or your conception of the problem itself around OOP." It's 2020, and after 50+ years of programming language research I think it's safe to say that there is no "on…

> I think it's safe to say that there is no "one language to rule them all" or "one programming paradigm to rule them all. Absolutely! But when OOP was initially sold to the masses it was marketed to be that one solution to rule them all, OOP was the buzzword of the day and it stayed like that for some time to come. It is only fair that the king was dethroned to make room for equally good/competing paradigms. I don't…

I agree about OOP being marketed that way. I remember that time. Rejecting it utterly and making it an "anti-buzzword" is equally irrational. It's a tool. Use it when appropriate.

Re: The Case Against OOP Is Wildly Overstated

#49

Post by jcelerier » Fri, Jul 31, 2020, 2:59 PM UTC

clktmr wrote: post #27

> The solution to the fragile base class problem and other inheritance hangovers is surprisingly simple — don’t use it If OOP provides the footgun to shoot yourself, OOP is at fault. Overall the article reads as "OOP has no problems if is used correctly". Of course that's true. I have seen well designed OOP programs, but the majority was not. The author should ask the question, why OOP is applied the wrong way so oft…

> The author should ask the question, why OOP is applied the wrong way so often.

well, if universities started by teaching something else that "Cat" inherits "Animal" in 2020 ...

Re: The Case Against OOP Is Wildly Overstated

#50

Post by garethrowlands » Fri, Jul 31, 2020, 3:00 PM UTC

Kapura wrote: post #19

api wrote: post #3

Earlier quoted context omitted.

That sounds snarky. Not sure if that was intended or not, but regardless I read your comment as: "OOP is good when you use the object oriented structure as a tool to organize your code and data to solve a problem, but not when you try to wrap your solution or your conception of the problem itself around OOP." It's 2020, and after 50+ years of programming language research I think it's safe to say that there is no "on…

I program video games; I would consider running a real-time simulation as a "state-rich" problem domain. And the constraints of running real-time simulations mean that some implementations are not acceptable. Things are not generally allowed to be slow if they can be done in a way that is fast. Because of this, many game engines are built in a way that allows high throughput for processing the state of hundreds, perh…

Absolutely. And the kinds of data structures you get in an entity-component system are probably easier and more natural to use in a language such as Haskell than a typical OOP object-graph-of-mutating-objects would be. Not that anyone's programming their ECS in Haskell.