[zaphar]

Except that his talk is not anti-OOP. It's anti-a-specific-way of using OOP. Namely representing the Domain Model as the compile time hierarchy. He goes to great lengths that he himself uses OOP concepts in his code. OOP wasn't a mistake per-se. The mainstream way of using as promulgated by a number of experts was the mistake.

[mrkeen]

The problem is when you take out mistakes, there's not much left of OOP.

We take out 'dog-is-an-animal' inheritance.

We take out object-based delegation of responsibility (an object shall know how to draw itself). A Painter will instead draw many fat structs.

Code reuse? Per the talk, the guy who stumbled onto this was really looking for a List<> use-case, (not a special kind of Bus/LinkedList hybrid. He was after parametric polymorphism, not inheritance.

[vkazanov]

The problem is that once you exclude domain-specific hierarchy from the discussion, there's not much left of OOP.

It's just data + relevant functions. Which is ok.

That's all there is, really.

[mrkeen]

And Rich Hickey calls out even that last feature as a mistake, and I tend to agree.

https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd6...

[igouy]

> "OO is not bad when there is an actual entity - i.e. a stream, a socket, a window, etc to which an object corresponds, or in a simulation of actual entities. That's where it was born and where it shines. … For instance, don't customers buy products? Which should own the functions that involve both?"

What is the purpose of the customers / products app?

[MantisShrimp90]

You get it