Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case Against OOP Is Wildly Overstated

medium.com

Post reply on HN
Print view View original

241–250 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#241

Post by mhoad »

correct_horse wrote: post #216
AnimalMuppet wrote: post #149

Earlier quoted context omitted.

I'm not the one you're asking. But... Here's a data structure that represents a bill of materials. It has a list of components, and a total cost, which is the sum of the costs of the components on the list. That's the invariant - that the total cost is the sum of the costs of the components in the list. If it's just a structure, then someone can add or remove a component, and forget to update the total cost, and the…

This is generally accurate, but I want to highlight the awesomeness of opaque structs. In C you can declare a struct in a header file, but not its fields ie struct point;. Then in the corresponding c file you can write out the whole definition ie struct point {x: float; y:float;};. Any code that includes the header can pass pointers to struct point (or pointers to pointers, etc) but can't directly pass points around…

This might sound stupid but I have ONLY ever known OOP in the Ruby / C++ / Java sense before but this idea blew my mind as such an interesting and different way of thinking about it and I can't tell if it is just my own bias but my initial thought is that it seems like such an additional level of mental overhead that you would always have to carry around on top of everything else you already have to think about. I assume that becomes easy with time?

Re: The Case Against OOP Is Wildly Overstated

#242

Post by mhoad »

tabs_masterrace wrote: post #181
tgflynn wrote: post #41

Earlier quoted context omitted.

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.

Ideally you want to have all your state in one place, the "single point of truth", in tightly modeled data structures, keeping it as lean and immutable as possible. The program is then just a function of the state, consisting mainly of self-contained functions, that take arguments and produce a result, without causing side effects. Realistically, that doesn't mean there are no classes or objects with internal vars, b…

I must admit that does sound like a really nice code base to work inside of.

Re: The Case Against OOP Is Wildly Overstated

#243

Post by Noumenon72 »

gizmo385 wrote: post #99
dreamcompiler wrote: post #36

PSA: If you want people to read your tech posts, don't write them on Medium. Medium requires logging in to view their content now, so like Pinterest, Quora, etc they are dead to me. And I know I'm not alone.

Given that the post is ranked relatively highly on Hacker News at the moment, it would appear that there are people who are still reading their tech post even though it is on Medium :)

I paid for Medium because I was reading so much good tech content there.

Re: The Case Against OOP Is Wildly Overstated

#244

Post by demux »

addicted44 wrote: post #100
garethrowlands wrote: post #63

Earlier quoted context omitted.

A typical microservice tightly binds code and data, and it communicates via messages. So when a microservice is useful, it's an example of binding data and code being useful. Though when a microservice mutates something, it's typically persisted in a database or similar (and, you'd hope, not sprinkled throughout its code). But, yeah, a bunch of communicating microservices are a lot like communicating objects - for be…

Eventually data has to be bound to code. Otherwise you'd have apps where you either have functional code running and other apps that are displays of raw data. The engineering question is what layer is it appropriate to do so. Under traditional OOP (your pre functional forward Java/C#/OOP C++), the answer was that code is almost always bound to data. Haskell style functional programming binds code to data at the last…

Declarative programming is also an option, where data is directly encapsulated into state, and programming entails describing the state transitions. SQL is a basic example of this, but it's also generally possible in other languages (eg template metaprogramming in C++). Prolog is a really cool language that operates solely on this principle.

Re: The Case Against OOP Is Wildly Overstated

#245

Post by wvenable »

kryth wrote: post #229
wvenable wrote: post #159

Earlier quoted context omitted.

It's the most successful programming paradigm in history. I feel like being anti-OOP is like being anti-vax. It's so successful and ubiquitous that it's success becomes invisible and so people only focus on the failures or misuse. Complaining about OOP requires an entire object-oriented software stack to post your argument.

That doesn't make any sense. Being an anti-vaxxer is simply stupid, proven by real numbers and repeated experiments. Meanwhile, there are a lot of fair criticisms to OOP. Of course, a lot of them arise due to the fact that the skill floor for software development is quite low nowadays, but then again if we were all that smart, we'd just write C and C++ at the speed of light for everything. P.S: Rewriting hackernews i…

There are plenty of potential side-effects for vaccines as well. The last time I had one, I had a relatively unpleasant reaction.

So I'm not saying that there aren't fair criticisms of object-oriented programming. But "the case against OOP" is not proven by real numbers and repeated experiments. It's the most successful programming paradigm in history. The evidence for the success of OOP is more overwhelming than for any vaccine. Yet we're stilling debating boogeyman like mercury in vaccines and inheritance in OOP.

Re-writing hackernews in a functional stack might be trivial. But what about the web browser, the GUI environment, the OS kernel? OOP based software stacks are everywhere. And there is no need to re-write anything because it all works fine.

Re: The Case Against OOP Is Wildly Overstated

#246

Post by thom »

Barrin92 wrote: post #56
thom wrote: post #22

Earlier quoted context omitted.

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

Is it a wild simplification to suggest that the inner loop of every game is the state now, some processing at the current time step, and a new state to be rendered?

Re: The Case Against OOP Is Wildly Overstated

#247

Post by zaphar »

wvenable wrote: post #129
zaphar wrote: post #123

I respectfully disagree that frameworks and stdlibs for languages like Java and .Net are better due to use of Inheritance. In fact I struggle to come up with a single occasion where use of Inheritance was not an Antipattern. The exception I suppose is when you have no other way to do polymorphic interfaces.

Lots of things in software development have an is-a relationship. The only time inheritance is an antipattern is when it's used for code-reuse and it isn't modeling an is-a relationship. Once you get to application code there aren't a lot of is-a relationships but inside operating systems, libraries, and frameworks it does come up legitimately.

Is-a relationships are best handled by interfaces. If you don't have those and only have inheritance then that is the exception I mentioned above. In those cases I would argue that the base class should be composed entirely of abstract methods and the depth of the inheritance hierarchy should be no greater than 1.

Re: The Case Against OOP Is Wildly Overstated

#248

Post by cutler »

Apart from Rich Hickey's "Simple Made Easy" I think Joe Armstrong summed-up best the inherent problems with OOP as it exists in the most popular languages: "The problem with object-oriented languages is they've got all this implicit environment they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

Re: The Case Against OOP Is Wildly Overstated

#249

Post by juniper_strong »

dionian wrote: post #43
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.

Me too. I also violate it every day. Just this day I used System.out.println, for example.

Re: The Case Against OOP Is Wildly Overstated

#250

Post by dnautics »

AnimalMuppet wrote: post #141
dnautics wrote: post #29

Earlier quoted context omitted.

> In other words I'd consider OOP for a "state-rich" problem domain Why is a paradigm like FP necessarily bad for this? Not all FPs are pure like Haskell, and some exist specifically for the purpose of managing state in sane ways (for example which tolerate concurrency without introducing bugs).

Which FP languages do you think would be good for managing state? I've read here on HN the idea that FP is appropriate when you can think of your program like a pipe (data comes in, data goes out). To me, significant amounts of state would be antithetical to that. Is that view mistaken?

Julia, erlang. Beyond some point you're using a DB for state anyways.
Post reply on HN