Why OOP Exists

"Object thinking" by David West was eye opening about this back in the day. The gist is to model the objects not along the line of real world entities, but along the line of "behaviour" like you mention.

I agree.

I used to be OOP hater, but realized that it has it's place and some problems are OOP shaped and OOP is a wide range of techniques. I do think that python is a sloppy language and generally don't like it.

Functional programming has it's place and I love it and is probably what my mind goes to the most, but often in Functional languages I find you can 'over fit' to a particular way of doing things, And with OOP your get more degrees of freedom with things you can do with a class and things can be modified easier, think sort of problems like a board game just as an example treating the pieces as an object can make it easier to modify any section of the logic of the game and add new pieces then the typical functional approach.

I often have to teach basic OOP concepts to junior - mid level developers.

Many who've entered the career in the last decade or so seem to have missed what I 'd consider to be quite a fundamental grounding.

Not even advanced concepts from the gang of four book - though I have taught these too - but often just an un-awareness of OOP in general, even simple things like understanding encapsulation.

Frameworks and languages do evolve, but never being taught basic things like encapsulating state or exposing dependencies seems an issue. Very differnt from my own time as a junior when this stuff was constantly hammered home.

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.

Some problems don't require OOP, but most large complex problems do, IMO.

Most complex codebases I've seen which were pure Functional Programming were spaghetti code; unmaintainable.

What I saw every single time was that the project was syncing a huge amount of state in a central place and then passing it through a large number of components and sub-components. The top level component basically had to have full awareness of everything going on inside the system in order to do its job and there were no separation of responsibilities because none of the components had sovereignty over the state they needed to do their job independently. It's just components micro-managing components all the way down.

React with Redux is probably the best FP implementation I've seen thus far but even it is kind of a mess. I have nightmares about Redux Saga. The Redux Saga logo is literally a stylized drawing of entangled spaghetti.

Had Redux + Saga been presented to people as part of React at the time it was introduced, React would probably not have become so popular. Because people would have understood that it creates too much unnecessary baggage which isn't worth it. React was used as a gateway drug to Redux which was itself a gateway drug for Saga! And what I observed in practice is that most React apps are glitchy AF; and those glitches are usually difficult to reproduce and fix, even if you know all the ins and outs of the framework!

> this is just structs.

Yes. And structs are just bytes. Levels of abstractions don't do anything the underlying levels don't already do, they just give you means to express your intent in a clearer form.

But functional programming and OOP are intrinsically the same, but expressed using different primitives.

The thing that empowers first-class functions and closures (lexical binding) is the exact same method by which encapsulation works, even if the latter opts for heap vs stack. The fundamentals are the same.

Here's a simple one in Emacs Lisp:

    (defmacro send (object method &rest args)
      "Sends a METHOD to an OBJECT with ARGS."
      `(funcall ,object ',method ,@args))

    (defun make-animal (name)
      ;; 'hunger' is entirely private (encapsulated)
      (let ((hunger 5))
        ;; here's our lambda using lexical binding
        (lambda (method &rest args)
          (cond
           ((eq method 'get-name) name)
           ((eq method 'feed) 
            (setq hunger (max 0 (1- hunger)))
            "Yum!")
           (t (error "Animal does not understand: %s" method))))))

    (let ((good-boy (make-animal "Rex")))
      ;; "call" (via our macro) the "get-name" method; then feed. hunger does down 1.
      (send good-boy get-name)
      (send good-boy feed)
      ;; pretty-print the "object" good-boy
      (pp good-boy))

    ;; this is the state of it after the two calls.
    #[(method &rest args)
      ((cond ((eq method 'get-name) name)
             ((eq method 'feed) (setq hunger (max 0 (1- hunger))) "Yum!")
             (t (error "Animal does not understand: %s" method))))
      ((hunger . 4) (name . "Rex"))]

OOP is not about doing things harder, it‘s about doing them efficiently. The key elements of software engineering are abstraction and encapsulation: we, humans, cannot load the entire domain into our memory and reason about it at all levels of detail at once. We need to zoom in and zoom out, decompose problems into smaller pieces, then reassemble, treating those pieces at surface value. OOP isn‘t rocket science, it just adds one more piece — the hierarchy of concepts with inheritance and polymorphism. And it‘s just a technique: most programs are written in a mix of styles anyway. The foundational style is procedural, because that‘s how computers work. FP and OOP just build on top of it and translate to it.

The older I get the more I realize the stuff I learned in university was just plain wrong.

It's incredibly difficult now dealing with zoomers in the workplace that think I'm some old boomer that never learned "proper computer science".

No, sorry Timmy, it's not because I don't understand microservices, it's because I actually do.

Not sure if intentional, but I read it in Ylvis’ “What does the fox say?” and now I can’t get it out of my head, thank you very much.

Nah even traits are kinda bad because it increases the indirection necessary for code reading

OOP is sold on the promise that everything is modular. Since everything is neatly encapsulated with clearly defined API surfaces, you can easily swap out any part for any other. This should make developers interchangeable, because anyone can go in to the code and swap out parts as needed.

In reality this seems to make coupling even worse. Now you have to dig 8 classes deep just to find the business logic for a particular feature. Changing it is even harder because the rest of the program expects this part to behave in a very specific way.