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 :-)