Exploring the philosophy of objects

[Zoadian]

On Friday, 24 June 2022 at 14:11:51 UTC, Ola Fosheim Grøstad 
wrote:
> On Friday, 24 June 2022 at 13:48:35 UTC, Zoadian wrote:
>> And to add something to the topic. objects are a great why to 
>> think about things. they are, as it turned out, not they great 
>> in programming.
>> OOP leads to slow, hard to reason about code. it encurages 
>> mutable state, spread across the whole programm. it's 
>> essentially global variables all over again, just hidden 
>> behind a layer of obfuscation.
>> It also makes testing a lot harder to actually implement.
>> That being said, there are cases where it's ok to use, but 
>> imho they are incredibly rare.
>>
>> - Someone who works on hard realtime systems
>
> What you are describing is not the nature of OO-modelling, but 
> the consequences of people not knowing what they are doing, 
> using the wrong implementation strategy, tooling etc.
>
> Objects are appropriate also in real time systems. Actors are 
> objects on steroids and represents one valid approach to 
> creating reliable real time systems. Coroutines have a strong 
> relationship to objects and greatly reduces bug inducing tedium 
> of creating state machines, again an improvement for real time 
> systems if used by a critical thinker. Objects also makes it 
> easier to create transactional systems that allows you to roll 
> back, again a reliability advantage.
>
> No matter what domain you are in, if you deal with uncertainty 
> then also you need a proven methodology and tools that suits 
> the application domain you are working with. With no proven 
> methodology, especially geared towards what you are doing, 
> quality will become less predictable.
>
> If you have no need to maintain state modelling the 
> environment, then of course, you would also not need objects 
> and can choose dedicated tools with 100% verification of the 
> implementation. Is that better? Yes clearly, when you can get 
> away with it.
>
> The OP is relevant to D, because how people thing about objects 
> and their representation affects language design and usage. You 
>  confirmed this yourself by stating that you dislike OOP 
> because people are idiots and mess things up (which is the only 
> reasonable interpretation of what you stated). But that is not 
> a consequence of OO-modelling as a concept. It is a result of 
> poor modelling or poor implementation or poor tooling.

I'm not claiming objects are generally bad. But OOP in general is 
a bad design strategy if you want efficient programs. objects 
bundle too many different variables together, so cache access is 
most certainly suboptimal. multithreading is another thing that's 
much harder to do when you start with an OOP model in mind.
All these problems can be solved, at least to some extend, but 
IMHO it's not a good strategy for implementation. it's fine to 
model a system as OOP at first, restructure it to something more 
performant.
But I don't think i have to reiterate the points against OOP 
here, there are numerous articles on the internet talking about 
it.
Just to give you one example of a hilariously bad OOP 
implementation where you'd expect them to know better: chromium.