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

151–160 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#151

Post by antonvs »

Jtsummers wrote: post #134
commandlinefan wrote: post #122

Usually when I see people rant against OOP, they're not ranting in favor of FP (or even better, in favor of something like Scala that combines OOP and FP) but rather in favor of a return to procedural/top-down programming. There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones.

> There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones. Procedural programming does not, at all, require global variables to make it work. I'm not a big fan of procedural programming at scale because it almost always seems to assume mutability (by default) and shared state when dealing with concurrency, but let's…

That's basically a hand-rolled implementation of a state monad that supports real mutability. The Haskell equivalent is the ST monad.

While it's possible to do this kind of thing, it's busywork that properly designed programming languages are perfectly capable of handling well on our behalf.

Re: The Case Against OOP Is Wildly Overstated

#152

Post by meheleventyone »

addicted44 wrote: post #109
jayd16 wrote: post #89

Earlier quoted context omitted.

Hash maps hide lots of internal state though. I think the difference is hash maps have a clear, battle tested API and its obvious what should be promised by the interface and what should be internal implementation. Devs aren't clairvoyant so when we're making a new type we might sometimes get this wrong. But this is a fundamental issue with type systems in general and not OOP, is it not?

Hash maps also don't (usually) have external effects. There arent many hash map methods that will actually modify the data. Standard OOP, on the other hand, seems to encourage such behavior. So, for example, a Company object could contain a bunch of Department objects, each of which contained a bunch of Employee objects. These people objects could also be referenced in areas outside of the company object. If I called…

I think the problem is that your example is too contrived and you can hide implementation details by just having a function giveFinanceDepartmentARaiseInDollars(company, dollarAmount) that exhibits the same issues as the “object oriented version”.

More generally the issue of global mutable state and keeping your own sanity as a developer is a problem across paradigms.

Re: The Case Against OOP Is Wildly Overstated

#153

Post by pjmlp »

MasonOfSpoons wrote: post #145
jayd16 wrote: post #89

Earlier quoted context omitted.

Hash maps hide lots of internal state though. I think the difference is hash maps have a clear, battle tested API and its obvious what should be promised by the interface and what should be internal implementation. Devs aren't clairvoyant so when we're making a new type we might sometimes get this wrong. But this is a fundamental issue with type systems in general and not OOP, is it not?

It really isn't, as OOP languages don't traditionally provide robust mechanisms around immutability. And why would they? The core design of OOP is to wrap mutable state behind methods which control that mutation. OOP was in many ways a reaction to C; shared mutable structs are harmful, so let's invent privacy. Most of the languages which are suggested to be superior alternatives to OOP in this thread have immutable d…

You can already do that via modules or fake modules in C translation units.

What OOP offers on top of modules is extendability and polymorphism.

And these two capabilities are possible to achieve in various ways.

Re: The Case Against OOP Is Wildly Overstated

#154

Post by pjmlp »

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.

Modules with responsibility to handle the specific set of states, which are basically final classes.

Re: The Case Against OOP Is Wildly Overstated

#155

Post by winstonewert »

karpierz wrote: post #106
winstonewert wrote: post #82

Earlier quoted context omitted.

I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's…

In what versions of OO does a hash map hide the data? The definition of a map requires that you can access the data.

A hashmap wouldn't hide the data. But say, a Customer object might. A purist OO might insist that you shouldn't have a GetName() method because any code which needs the Customer's name should be method on Customer.

Re: The Case Against OOP Is Wildly Overstated

#156

Post by wvenable »

phendrenad2 wrote: post #131

OOP is a crazy academic-esque idea that happened to stick because it works at scale. When you have hundreds of programmers working on a codebase, it's useful to constrain people with UML diagrams and rigid hierarchy. Otherwise, cowboy coders hack up something the other 90% of coders can't understand. This is why languages like Scala and Haskell haven't taken off outside of a few small-team-focused niches, like data s…

> OOP is a crazy academic-esque idea that happened to stick because it works at scale.

I suppose it's weird to be young enough that you're first exposure to OOP is it being taught in an academic environment. It must make it seem like it was dreamed up like some kind of formalism and spewed into your brain.

But before OOP languages and everything that you describe, people using plain old procedural languages were already coding in an OOP style because it's obviously beneficial. Languages later came along to formalize patterns that people had used for years. For a more modern example you just have to look at the Linux kernel which includes a lot of OOP principles even though it's all just C.

Re: The Case Against OOP Is Wildly Overstated

#157

Post by mark-r »

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…

Yes, it does seem like OOP and functional are on opposite sides of a spectrum. OOP is all about having and controlling state, while functional is about being stateless. I think my own code would benefit from being more functional, but that's hard to do in a OOP infrastructure.

Re: The Case Against OOP Is Wildly Overstated

#158

Post by noisy_boy »

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…

Having used Django's ORM, SQLAlchemy and JPA (via Spring Boot), it depends on the ORM. E.g., JPA's automatic query generation[0] is very convenient while still allowing plenty of options for handcrafted SQL, if needed. I'm the kind of person who enables logging of ORM generated SQL so that I can see exactly whats going on under the hood; so far, many hours saved with very few complaints. This assumes a well defined database model - if that has issues, all bets are off.

[0]: https://docs.spring.io/spring-data/jpa/docs/current/referenc...

Re: The Case Against OOP Is Wildly Overstated

#159

Post by wvenable »

drummer wrote: post #111

OOP has served me well. It is a powerful concept. Problem is that people can misuse and abuse things.

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.

Re: The Case Against OOP Is Wildly Overstated

#160

Post by winstonewert »

jayd16 wrote: post #89
winstonewert wrote: post #82

Earlier quoted context omitted.

I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's…

Hash maps hide lots of internal state though. I think the difference is hash maps have a clear, battle tested API and its obvious what should be promised by the interface and what should be internal implementation. Devs aren't clairvoyant so when we're making a new type we might sometimes get this wrong. But this is a fundamental issue with type systems in general and not OOP, is it not?

Sure, hash maps hide lots of internal state which isn't relevant to outside code.

Where things would get silly is if you tried to make all state internal. But that's what some purist OO approaches would do for business objects.

Post reply on HN