The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#51

Post by lgessler » Fri, Jul 31, 2020, 3:01 PM UTC

tgflynn wrote: post #41

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.

Essentially, yes, but in a way that sounds more careful than what you saw in that Fortran program. If it absolutely has to be stateful, like with a db connection for example, then there's no getting around that, but what you can do is (1) not bury it in a bunch of stateful objects that didn't have to be stateful, which can cause cascading errors when either one of them misbehaves and also makes it difficult to isolate any one stateful component for testing or re-use, and (2) use special wrappers around it that will make the statefulness easier to deal with. (For examples of (2), see Clojure atoms and the Clojure library mount: https://github.com/tolitius/mount )

Re: The Case Against OOP Is Wildly Overstated

#52

Post by 3pt14159 » Fri, Jul 31, 2020, 3:01 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…

I like certain aspects of Django, but Rails got models and migrations better. Writing raw SQL for everything gets old, and I'm someone that loves SQL when it's the right call for the job.

And I agree with you on inheritance. One level max for production code, one additional level for tests that need to change a method here or there to get them to work. That's it.

Re: The Case Against OOP Is Wildly Overstated

#53

Post by eternalban » Fri, Jul 31, 2020, 3:04 PM UTC

PaulHoule wrote: post #34

tempodox wrote: post #18

IMO, OOP just puts too many footguns at your disposal, the most dangerous one being mutability (how normal is it that our methods mutate instance variables?). The larger a system grows the more mutability will make it even harder to understand and control. It may be tolerable in small-scale embedded software, but outside of that we should make use of the better alternatives that modern hardware affords us.

I knew a professor who worked on Density Functional Theory which can be used to derive many of the properties of materials from first principles. (e.g. "Does Iron Conduct Electricity?") This involved running FORTRAN programs on what was then considered a large supercomputer (256 nodes.) Asked what he thought about any programming technique that cost a factor of 2 in performance and he told me it was a non-starter whe…

HPC obviously prefers higher performing approaches, but how is this anecdote relevant to general programming community?

The position that x2 "isn't much in the grand scheme of things" is a reasonable position. Note the "grand scheme" qualifier. Also the implicit here is "we trade performance for ---". The professor was making a sensible statement about tradeoffs when considering 'general programming approaches'.

Your last line also reads like a potshot at Rich Hickey.

I think the actual failure of OOP is that it did -not- result in the desired outcome of addressing the "software crisis" [1] and the significant imbalance between the scale of required (new) software and available human resources to write these systems. A subset of programmers can use OOP to build very effective systems; the rest shoot themselves in the foot. That is the failure of OOP.

But I am curious if any other software methodology prevents underskilled developers from shooting their own feet. AFAIK the answer is a definitive 'No'.

[1]: https://en.wikipedia.org/wiki/Software_crisis

Re: The Case Against OOP Is Wildly Overstated

#54

Post by yobi-ponti » Fri, Jul 31, 2020, 3:04 PM UTC

qmmmur wrote: post #7

There is no 'case' to be made against any paradigm. Different hats for different jobs.

It has become popular to hate OOP so now people find every opportunity to discredit it. But yeah, every tool has a purpose. Don't like it in your workplace? Make a fact based case against it and do something about it.

Re: The Case Against OOP Is Wildly Overstated

#55

Post by _28jh » Fri, Jul 31, 2020, 3:04 PM UTC

The author flatly says "do not use inheritance." Without inheritance and polymorphism, what is left in OOP? If you look at the author's 4 pillars, the only thing left is encapsulation (and "Oversimplified Hot Takes") It seems like the author himself has proven why OOP is bad. You can have encapsulation without OOP. People were doing it in C 40 years ago. And people are doing it in Go right now. No one would call Go an OO language, yet it has what the author admits is OOP's only good feature.

Re: The Case Against OOP Is Wildly Overstated

#56

Post by Barrin92 » Fri, Jul 31, 2020, 3:06 PM UTC

thom wrote: post #22

Barrin92 wrote: post #13

Earlier quoted context omitted.

The entire point of OOP is to encapsulate state within objects and to have objects communicate through messages, that is to say to 'program without a center'. Global or interconnected state is if anything a violation of OO principles. In proper OO state is hidden and insofar as it causes issues it does so in a way that is handled by the object rather than the program overall. Also treating code as data isn't a featur…

I'm not sure you're responding directly to the point the parent made. Even if state is encapsulated, objects are mutable. Many people believe reasoning about programs in which lots of mutable objects coordinate is harder than some of the alternatives (e.g. pure functions, immutable data etc).

depends on the domain. In anything that has say, a very structured 'data flow' in one direction, like in finance or accounting or versioning immutability works well as a concept. In other domains like say, game development it feels forced and out of place.

If actual usage of paradigms is an indication rather than belief then it doesn't look like functional programming really is intuitive, it tends to be very useful in certain niches.

Re: The Case Against OOP Is Wildly Overstated

#57

Post by john-shaffer » Fri, Jul 31, 2020, 3:07 PM UTC

PaulHoule wrote: post #34

tempodox wrote: post #18

IMO, OOP just puts too many footguns at your disposal, the most dangerous one being mutability (how normal is it that our methods mutate instance variables?). The larger a system grows the more mutability will make it even harder to understand and control. It may be tolerable in small-scale embedded software, but outside of that we should make use of the better alternatives that modern hardware affords us.

I knew a professor who worked on Density Functional Theory which can be used to derive many of the properties of materials from first principles. (e.g. "Does Iron Conduct Electricity?") This involved running FORTRAN programs on what was then considered a large supercomputer (256 nodes.) Asked what he thought about any programming technique that cost a factor of 2 in performance and he told me it was a non-starter whe…

Clojure isn't supposed to be everything for everyone. Did Hickey really dismiss the value that 2x faster had for the professor, or was he just not interested in that particular use case for himself?

Re: The Case Against OOP Is Wildly Overstated

#58

Post by tempodox » Fri, Jul 31, 2020, 3:09 PM UTC

PaulHoule wrote: post #34

tempodox wrote: post #18

IMO, OOP just puts too many footguns at your disposal, the most dangerous one being mutability (how normal is it that our methods mutate instance variables?). The larger a system grows the more mutability will make it even harder to understand and control. It may be tolerable in small-scale embedded software, but outside of that we should make use of the better alternatives that modern hardware affords us.

I knew a professor who worked on Density Functional Theory which can be used to derive many of the properties of materials from first principles. (e.g. "Does Iron Conduct Electricity?") This involved running FORTRAN programs on what was then considered a large supercomputer (256 nodes.) Asked what he thought about any programming technique that cost a factor of 2 in performance and he told me it was a non-starter whe…

Yes, HPC is certainly a separate domain as much as embedded is. You cannot transfer (what I would call) conventional wisdom and expect a reasonable outcome or a working system at all.

Re: The Case Against OOP Is Wildly Overstated

#59

Post by [deleted] » Fri, Jul 31, 2020, 3:09 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…

[deleted]

Re: The Case Against OOP Is Wildly Overstated

#60

Post by _old_dude_ » Fri, Jul 31, 2020, 3:10 PM UTC

throwaway894345 wrote: post #35

michaelcampbell wrote: post #11

Earlier quoted context omitted.

OOPs original premise is homoiconicity? Really?

I'm not sure "code is data" necessarily means "homoiconicity", but it could mean "first-class functions" (or at least that's what I think of when I hear the phrase; maybe I'm wrong); however, I'm not familiar with anyone who argues that these are fundamental OOP features (perhaps Smalltalk had first class functions, but for a very long time the most popular flavors of OOP did not).

yes,

Homoiconicity is about having the same syntax for both structure and data.

First class functions means there is no conversion, again at syntax level, between a function and a value.

Mainstream languages all have a way to see code as data, it's function pointer in C, delegate and lambda in C# and first class functions in Python or JavaScript.