Exploring the philosophy of objects

[Ola Fosheim Grøstad]

On Friday, 24 June 2022 at 14:30:54 UTC, Zoadian wrote:
> I'm not claiming objects are generally bad. But OOP in general 
> is a bad design strategy if you want efficient programs.

The Simula class concept is to a large extent meant to support 
changing the model later. So it is sensible for simulation where 
you experiment (programming cost being higher than hardware 
costs). This is basically where inheritance comes in. You have a 
working model, then someobody tells you: we actually need to 
model not only Doctors, but also Nurses, AmbulanceDrivers etc. 
How quickly can you accomodate that wish? This is also a strength 
of relation-based databases, just add more tables.


> All these problems can be solved, at least to some extend, but 
> IMHO it's not a good strategy for implementation.

I don't think existing languages have good support for hardware. 
C++/C requires the compiler to use the same layout for fields in 
a record as the source. That is a bummer for inheritance in terms 
of cache-lines, but that is not an OO weakness, it is a language 
weakness.

If we talk high level OO, then there should be no hard 
relationship between the code and the layout (e.g. it could 
broken down to structs of arrays or arrays of structs or 
components etc by the compiler based on hints or analysis).

Main stream languages are very primitive still… Outside of Rust, 
many languages seems to be satisfied by adding a thin layer over 
LLVM…

> it's fine to model a system as OOP at first, restructure it to 
> something more performant.

Sure, you can implement an OO-model in C or assembly. Most games 
of the 80s probably had some ad hoc OO-model implemented in 
clever ways in assembly to pack it into 32/64K RAM :-)