OOP hate is definitely a popular way to signal that you aren't just a "common grunt programmer". And there are personalities who have made it a big part of their appeal.
But I also spent some time with modern Spring Boot, and I get where the hate is coming from. There is a lot of complexity that just doesn't seem necessary at all.
> But I also spent some time with modern Spring Boot, and I get where the hate is coming from. There is a lot of complexity that just doesn't seem necessary at all.
I'm sure there is some (very high) level of inherent project complexity where the massive number of abstractions and tools that Spring Boot gives you (and forces on you) actually starts turning into a net positive... And I'm also fairly sure that most projects don't quite break even, and would be better off with something more lightweight.
the functionality is often necessary and useful the question is if they're required to be implemented in the way that they are or if there is a simpler approach.
also a lot of oop hate is 1) hatred of compile-time hierarchies attempting to match the domain model and 2) all the complexity in oop systems which isn't really inherent to OOP but made possible by it. oop doesn't require a PrototypeFactoryInjectorFactoryBean but it doesn't prevent you either :)
on the flip side I've seen functional codebases which are also full of complexity because of how fragmented everything is, like 20 functions all applied when it could have been a single imperative one making it hard to keep track of what is happening.
I think the hate typically comes from the mis-application of various tools; overly complex solutions for simple problems. There's nothing wrong with patterns per say, or frameworks that have complex building blocks for every conceivable permutation of relatively common issues. However, when people reach for unnecessarily complex tools out of laziness/habit, some hate is justified. I suspect this is very similar to what you're saying, and of course, it's not OOP specific. Functional languages have their patterns too, but instead of a famous book enumerating them, we have a famous blog post stating that functional languages are so awesome that they don't need patterns (or at least, this is how most people seem to interpret it).
Well, I just wrote a comment that could be considered an "OOP hate". I was debating whether to do it.
The point is not to be snug about it. Functional programming (and monads) are actually simpler. You just need to resist the urge to "make it more understandable".
Abstract math doesn't have good analogies to the real world. By trying to make an analogy with the concrete ("monads are mappable") you lose simplicity.
Monads might be simple but it's easy to create confusing large stacks of monad transformers in the haskell world, At least I have found and can often become not the most pleasant to work with aliasing complex monad stacks and all the rest, It can really lose elegance. Some problems beautifully fit as Monads and single monad code can be nice indeed but a few transformers and you can end up with a lot of mess. I do think there is some things that functional programming paradigm struggles with like games programming and other things, I really do think OOP is a better choice for some problems.
That relates to another misunderstanding. These ideas like "everything is a function" or "everything is a category" are not there to help you understand complex system better.
They are supposed to help you build better foundations; the abstractions to better understand your complexity you need to build (or at least pick) yourself.
Good foundations then help you relate the abstractions. For example, the categoric dual of a product is a sum. We can apply it to relation (relational algebra), and we get that sum is data inheritance.
So that gives you understanding of how functions (foreign keys), product (relation) and sum (inheritance) fit together. This sometimes helps to build abstractions in a consistent way.
Oh, I agree. But there's value in people who set out to do things a certain way, even if that approach ends up not working well in the long term.
We're collectively shaking a lot of trees when we build frameworks, languages and tools. What works? What does not? What is the right level of abstraction? How much developer ergonomy do we want to sacrifice?
Sadly we only seem to know in hindsight what works well. But that is also how we learn and grow; it was just meant to be this way.
But I also spent some time with modern Spring Boot, and I get where the hate is coming from. There is a lot of complexity that just doesn't seem necessary at all.