[jacquesm]

One of the main issues with this is that OO as practiced in C# and Java is only a very thin extract from the real OO as provided by for instance Smalltalk. And without that kind of environment you end up with the worst of both worlds, where you have an OO like interface layered on top of things that aren't really objects to begin with, because they aren't 'alive'.

[aksss]

Very good observation but I do wonder whether it’s the worst of both worlds or the best of both worlds - more the “eat the meat and spit out the bones” approach?

[tombert]

I feel this kind of argument is a bit pedantic though; when people complain about OOP, they're generally complaining about the mainstream implementations of OOP.

I don't think that people people are really considering Smalltalk's OOP style when they complain about Java OOP.

[jacquesm]

This is far from pedantic. Calling something OOP when it isn't is a huge part of the problem.

[xmcqdpt2]

One might say that Real OOP has never been tried.

[pmontra]

Erlang and Elixir with spawn processes (objects with their own CPU) and send / receive message passing? But they do their best to hide it in OTP behind all that handle_* boilerplate.

[whstl]

There's Smalltalk. And Ruby gets pretty close to Smalltalk, but yeah, in practice it ends up looking like very close to Java. Your point stands.